Question

Edit: it’s NOT an assignment of a function declaration to a named variable – check the accepted answer. Leaving title as it is because other people might make the same error as me.

---

While reading Paul Irish’s infinitescroll jquery plugin code, I stumbled again and again over the following pattern:

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

What is the benefit of doing this instead of:

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

Answer 1

The benefit of that (which is called a “named function expression”) is that the function has an actual name. In your second version, the property has a name, but the function doesn’t. Giving functions actual names helps your tools help you (call stack listings, breakpoint listings, etc.) More: Anonymouses anonymous

The disadvantage to it is that it has unexpected results in some broken JavaScript engines, like the one in IE8 and earlier. In IE8 and earlier, Paul Irish’s version creates two separate functions at two completely different times. But it’s not really a problem unless you keep and use references to both of them, and expect them to be the same function (for instance, when hooking up and unhooking event handlers). Given it’s Paul, I’m guessing he’s being sure not to do that.

---

Re your question title: Note that it’s not a function declaration, but you can be forgiven for thinking it is, as it looks almost exactly like one. 🙂 It’s a function expression. Function declarations and function expressions happen at completely different times, and have different impacts on the scope in which they’re created.

Just for completeness:

// This is a function declaration -- note that it's not a "right-hand
// value", e.g., 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's 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's 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