Geek Answers Handbook

Why should I assign a function declaration to a named variable?

Edit: This is NOT the purpose of a function declaration for a named variable - check the accepted answer. Leaving the name because other people can make the same mistake as me.

While reading the Paul Irish infinitescroll jquery code, I came across the following pattern again and again:

... _create : function infscr_create (options, callback) { /* ... */ }, ...

What is the advantage of this, and not:

 ... _create : function (options, callback) { /* ... */ }, ...
+4
source share
2 answers

The advantage of this (called the "named functional expression") is that the function has an actual name. In your second version, the property has a name, but there is no function. Providing actual function names helps your tools help you (call stack lists, breakpoint lists, etc.). More: Anonymous Anonymous

The disadvantage of this is that it has unexpected results in some broken JavaScript machines, like IE8 and earlier. In IE8 and earlier, the Paul Irish version creates two separate functions two completely different times . But this is not a problem if you do not keep and use links for both of them, and expect them to be the same function (for example, when connecting and disconnecting event handlers). Given this Paul, I assume that he will not do this.

Enter the name of the question: note that this is not a function declaration, but you can be forgiven for thinking that it is because it looks almost the same as one. :-) This is a function expression. Function declarations and function expressions occur at completely different points in time and have different effects on the area in which they are created.

For completeness only:

 // This is a function declaration -- note that it not a "right-hand // value", eg, we're not using the result of it immediately (via an // assignment, a property initializer, calling it, or passing it into // a function as an argument -- none of those). // // Declarations happen upon entry to the scope (not as part of step-by- // step code). The function name is added to the scope in which it's // declared. Declarations are illegal inside branches (`if`, `try/catch`, // `for`, etc.), but some engines will rewrite them as expressions for // you if you do that. Others will not, they'll just always declare the // function regardless of whether the code was reached. So don't do that. function foo() { } // These are all anonymous function expressions. The function in the // expression has no name, although some debuggers are pretty smart // about looking at the expression and (where they can) listing a // kind of pseudo-name for the function. Others are not that smart, // which is why I avoid anonymous functions. // // Expressions happen when they're reached in step-by-step code. var f = function() { }; var obj = { prop: function() { } }; doSomethingCoolWithAFunction(function() { }); (function() { })(); // Call it immediately !function() { }(); // Call it immediately ~function() { }(); // Call it immediately, there are a few variants // These are all *named* function expressions. // // Since they're expressions, they happen when they're reached in the // step-by-step code. The function name is NOT added to the containing // scope (except by engines with bugs). // // These are the same examples as above, but with a name. No other changes. var f = function foo() { }; var obj = { prop: function foo() { } }; doSomethingCoolWithAFunction(function foo() { }); (function foo() { })(); // Call it immediately !function foo() { }(); // Call it immediately ~function foo() { }(); // Call it immediately, there are a few variants
+6
source
  • A function has a name, not an anonymous function; this is displayed in debug traces, which makes debugging easier.
  • A function can invoke use itself by calling infscr_create()
+5
source

More articles:


All Articles