Why does the Airbnb style guide say that relying on function name inference is discouraged?

// bad
class Listing extends React.Component {
  render() {
    return <div>{this.props.hello}</div>;
  }
}

// bad (relying on function name inference is discouraged)
const Listing = ({ hello }) => (
  <div>{hello}</div>
);

// good
function Listing({ hello }) {
  return <div>{hello}</div>;
}

This is taken from the Airbnb react style guide. Can someone please explain why "relying on function name inference is discouraged"? Is it just a style concern?

I think this could also have something to do with the unexpected behaviour that you might run into from implicitly giving a lexical name to what you may expect to be an anonymous function.

Say for example someone understood the arrow function:

(x) => x+2;

To have the regular function equivalent:

function(x) {
  return x+2;
}

It would be pretty easy to expect this code:

let foo = (x) => x+2;

To then be the equivalent of:

let foo = function(x) {
  return x+2;
}

Where the function remains anonymous and would be incapable of referencing itself to do things like recursion.

So if then, in our blissful ignorance, we had something like this happening:

let foo = (x) => (x<2) ? foo(2) : "foo(1)? I should be a reference error";
console.log(foo(1));

It would successfully run because that function obviously wasn't anonymous:

let foo = function foo(x) {
  return (x<2) ? foo(2) : "foo(1)? I should be a reference error";
}  

This could potentially be exacerbated by the fact that in other situations where Babel implicitly adds a name to anonymous functions, (which I think is actually a bit of a side-effect of supporting implicit function names in the first place, though I could be wrong on that), they correctly handle any edge cases and throw reference errors where you would expect.

For example:

let foo = {
  bar: function() {}
} 

// Will surprisingly transpile to..

var foo = {
  bar: function bar() {}
}; 


// But doing something like:

var foo = {
  bar: function(x) {
    return (x<2) ? bar(2) : 'Whats happening!?';
  }
}

console.log(foo.bar(1));

// Will correctly cause a ReferenceError: bar is not defined

You can check 'view compiled' on this quick DEMO to see how Babel is actually transpiling that to maintain the behaviour of an anonymous function.

In short, being explicit with what you are doing is typically a good idea because you know exactly what to expect from your code. Discouraging the use of implicit function naming is likely a stylistic choice in support of this while also remaining concise and straightforward.

And probably hoisting. But hey, fun side trip.

EDIT #2: Found AirBnbs reason in their Javascript style guide

Don’t forget to name the expression - anonymous functions can make it harder to locate the problem in an Error's call stack (Discussion)

Original answer below

MDN has a good run-down on how function name inference works, including two warnings:

Observations

There is non-standard <function>.name inference behaviour in the following two scenarios:

1. when using script interpreters

The script interpreter will set a function's name property only if a function does not have an own property called name...

2. when using js tooling

Be careful when using Function.name and source code transformations such as those carried out by JavaScript compressors (minifiers) or obfuscators

....

In the uncompressed version the program runs into the truthy-branch and logs 'foo' is an instance of 'Foo' whereas in the compressed version it behaves differently and runs into the else-branch. Therefore, if you rely on Function.name like in the example above, make sure your build pipeline doesn't change function names or don't assume a function to have a particular name.

What is function name inference?

The name property returns the name of a function, or (before ES6 implementations) an empty string for anonymous functions

function doSomething() {}

console.log(doSomething.name); // logs "doSomething"

Functions created with the syntax new Function(...) or just Function(...) have their name property set to an empty string. In the following examples anonymous functions are created, so name returns an empty string

var f = function() {};
var object = {
  someMethod: function() {}
};

console.log(f.name == ''); // true
console.log(object.someMethod.name == ''); // also true

Browsers that implement ES6 functions can infer the name of an anonymous function from its syntactic position. For example:

var f = function() {};
console.log(f.name); // "f"

Opinion

Personally I prefer (arrow) functions assigned to a variable for three basic reasons:

Firstly, I don't ever use function.name

Secondly, mixing lexical scope of named functions with assignment feels a little loose:

// This...
function Blah() {
   //...
}
Blah.propTypes = {
 thing: PropTypes.string
}
// ...is the same as...
Blah.propTypes = {
 thing: PropTypes.string
}
function Blah() {
   //...
}

// ALTERNATIVELY, here lexical-order is enforced
const Blah = () => {
   //...
}
Blah.propTypes = {
    thing: PropTypes.string
}

And thirdly, all things being equal, I prefer arrow functions:

• communicate to reader that there is no this, no arguments etc
• looks better (imho)
• performance (last time I looked, arrow functions were marginally faster)

EDIT: Memory snapshots

I was listening to a Podcast and guest told of a situation were he had to deal with the limitations of using arrow functions with memory profiling, I have been in the exact same situation before.

Currently, memory snapshots will not include a variable name - so you might find yourself converting arrow functions to named functions just to hook up the memory profiler. My experience was quite straightforward, and I'm still happy with arrow functions.

Plus I've only used memory snapshots once, so I feel comfortable forgoing some "instrumention" for (subjective) clarity by default.

This is because:

const Listing = ({ hello }) => (
  <div>{hello}</div>
);

has an inferred name of Listing, while it looks like you are naming it, you actually aren't:

Example

// we know the first three ways already...

let func1 = function () {};
console.log(func1.name); // func1

const func2 = function () {};
console.log(func2.name); // func2

var func3 = function () {};
console.log(func3.name); // func3

what about this?

const bar = function baz() {
    console.log(bar.name); // baz
    console.log(baz.name); // baz
};

function qux() {
  console.log(qux.name); // qux
}