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

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 .name inference behaviour in the following two scenarios: 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... 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.