Styjun

There is one significant difference between the two: The latter one has a name.

I like to help my tools help me, and so I mostly avoid anonymous functions as my tools can't give me meaningful information about them (for instance, in a call stack list in a debugger, etc.). So I'd go with the

(function()
 function invokeMe() 
 /*code*/
 
 setTimeout(invokeMe, 5);
)();

...form in general. Rules are meant to be broken, though, not slavishly bowed to. :-)

Note that according to the specification, there's a third alternative: You can have an inline function that also has a name:

(function()
 setTimeout(function invokeMe() /*some code here*/ , 5);
)();

The problem, though, is that every version so far of the JavaScript interpreter from Microsoft ("JScript"), including (astonishingly) the one in IE9, handles that named function expression incorrectly and creates two completely distinct functions at different times. (Proof, try it in IE9 or earlier and also in just about any other browser.) IE gets it wrong in two ways: 1. It creates two separate function objects, and 2. As a consequence of one of those, it "bleeds" the name symbol into the enclosing scope of the expression (in clear violation of Section 13 of the specification). Details here: Double take

IMO, declaring a function will be useful only if you intend to re-use it later, in some other way.

I personally use function expressions (first way) for setTimeout handlers.

However you might want to know the differences between function declarations and function expressions, I recommend you the following article:

• Named function expressions demystified

I suggest a full duel between opposing team members to settle such arguments.

More seriously, in the end it just doesn't matter. The first form (non-named functions) tends to get unwieldy with larger functions, but isn't a big deal at all with small (1-2 line) functions. The second form is similarly harmless.

Any argument against either style is pure bikeshedding, imo.

An inline function avoids namespace pollution and predefined functions have higher reuse. I think you could make cases where each is appropriate.

I think that the only difference in a code like that is that with the second piece of code you can re-call the same function (sometimes with "timer functions" it's useful):

(function()
 function invokeMe() 
 if(..) setTimeout(invokeMe, 5);
 
 setTimeout(invokeMe, 5);
)();

Can't we all just get along?

(function()
 setTimeout( (function InvokeMe() /*some code here*/ ), 5);
)();

Only one thing really matters, IMO and that's ease of debug. A lot of step tracers won't be able to tell you anything about the func other than the fact that it was anonymous and had args but you can still define inline with a name by putting the definition in parens to force evaluation. For very simple or obvious breaking funcs, I suppose it's not a big deal but to me it's like semis. I really don't care what the other guy does if it doesn't cause pain but I try to always name my funcs because it's not hard and it can be an advantage.

I know, that this is an old question,
but to me there is an even more important difference than the ones already mentioned.
hoisting
Every function has to be created and therefore reserves some space in memory and eventually has to be GC later.

Named functions get hoisted to the beginning of the surrounding function, and are therefore created on every function call, wether they get used or not.
Anonymous functions get created only if the code that defines them is executed.

//an example where you wold prefer to use an anonymous function.
//you can assign this (anonymous) function to a variable, so you get your "name" back.
function someFn()
 if(condition)
 //the variable declaration has been hoisted, 
 //but the function is created at this point, and only if necessary.
 var process = function(value)/* */;
 switch(condition2)
 case 1: process(valueFor1); break;
 case 2: process(valueFor2); break;
 /* ... */
 
 


function someFn()
 var process;
 if(condition)
 process = function(value) /* A */ 
 else
 process = function(value) /* B */ 
 

 //beware, depending on your code, "process" may be undefined or not a function
 process(someValue);



//an example where you would prefer (/ utilize) the hoisting.
function someFn()
 /* some code */
 while(condition)
 //some might want to keep the function definition near the code where it is used,
 //but unlike an anonymous function or a lambda-expression this process-function 
 //is created only once per function-call, not once per iteration.
 function process(value, index) /* ... */ 
 /* ... */
 process(value, index)
 

so, as a rule of thumb:

• inside a loop there should be no anonymous function or lambda-expression




• if you need the function only inside of a (rarely true) condition you should prefer anonymous functions over named ones, since they are only created when needed




• if you know your buisness (JavaScript), you know when to ignore this advice

The predefined named functions can reduce the JavaScript callback hell issue, which is mentioned at http://callbackhell.com/

There are no technical reasons to prefer one version over the other. For me is usually depends on two things:

1. I want to resuse the passed callback in another context. In this case I define the function standalone and pass the reference.


2. The callback is larger than ~10 lines of code and the function expects additional arguments after the callback. In this case it is hard to reconstruct, which values are actually passed to the function.

Example:

setTimeout(function() // I need to scroll to see the other arguments

 // many lines of code

, 0); // <- where does this '0' belong to?

I prefer to use named functions. Named functions show by name on all debuggers (air, firebug, IE).

Example:

Notice that you can also have inline named functions like

 method: function obj_method()

This way, when you look at the stack trace, you'll see function obj_method instead of anonymous.

Were you asking about when to inline a function rather than declare it? When it makes sense in the code. If you need it from two different places, it can't be inline. Sometimes inline make the code easier to read, sometimes harder.

I tend towards named functions as well. Anonymous function refs are quick, but should only be used for simple stuff. My rule of thumb is that if the function is more than 2 lines of code, it probably belongs in it's own definition.

This is complicated by most example code making use of Anonymous functions. But the samples are usually very simplistic. The method falls apart as things get more complicated. I've seen function refs nested in function refs as the developer realized that more callbacks were needed in subsequent steps. Instead of this tree based logic, I prefer the organization of isolated functions.

And usually end up happy that I can reuse one of the functions I define later.

One important use of an Anonymous Function is when you need to pass scoped data into your function call, but then I usually just wrap my function into the anonymous function.

Named functions are also absolutely necessary if you ever get into Test Driven Development.

In the example provided, the declaration and use of the function are so close that I think the only difference is readability. I prefer the second example.