4

Possible Duplicate:
What do parentheses surrounding a JavaScript object/function/class declaration mean?

Recently discussing with a colleague which is best

(function(){...}())

or

(function(){...})()

I got to wondering what ( ... ) actually does at a fundamental level, and what is the difference between what the js engine does in both the above cases. Is one approach theoretically (even if only a tiny amount) faster than the other? If my function returns an object what does ( .. ) do to the object in the first example?

Can anyone explain.

*edit The closest I've got to an explanation on the internet is http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#question-about-surrounding-parentheses, but this stops short, in my view, of explaining why the first example above works at all.

Community
  • 1
  • 1
wheresrhys
  • 22,558
  • 19
  • 94
  • 162
  • Even if there is a difference performancewise (which i highly doubt, but for argument's sake), **it doesn't matter.** You're going to be manipulating DOM objects, looping over stuff, etc etc etc. We're talking about *millions to billions+* of CPU cycles here. You will never notice the cycle or two you *might* save unless you're running some retarded micro-benchmark. – cHao Feb 03 '12 at 15:08
  • I'm not interested in this for performance reasons (although I am curious whether there is a minimal performance difference) - I just want to know what the js engine does when it interprets ( ... ) – wheresrhys Feb 03 '12 at 15:09
  • In almost all cases, where `(x)` and `x` are syntactically valid, `(x)` is exactly equivalent to `x`. The only exception i'm aware of is function statements, which are actually illegal as parts of expressions, but morph into function *expressions* when parenthesized or otherwise used as part of an expression. It's a little odd, but it works. – cHao Feb 03 '12 at 15:13
  • I've had a look at the other possible duplicate questions (http://stackoverflow.com/questions/3720283/what-is-this-practice-called-in-javascript, http://stackoverflow.com/questions/423228/difference-between-function-and-function, http://stackoverflow.com/questions/440739/what-do-parentheses-surrounding-a-javascript-object-function-class-declaration-m and a) They are not exact duplicates - this question is more theoretical in nature b) The content of the answers below doesn't duplicate the answers to those questions... so have a heart, and please vote to reopen. – wheresrhys Feb 03 '12 at 15:24

2 Answers2

3

You don't even need parentheses at all. The whole idea of those parentheses is to force a function to be an expression and not a declaration. You can also achieve that like

!function() {
}();

That exclamationmark could also be + or - and some other characters. So, it makes no difference whether you are using the "dog balls" version (your latter one) or not. From a performance aspect, I can't guarantee but I'm 99.9% sure there is zero difference (maybe engine dependent variation at best).

So if we assume that there is no performance difference between those two, its pretty much personal preference which one you use. The Crock many times declared the second version as "dog balls" because you don't wrap the whole expression anymore. I'd agree on that. As mentioned before, the pattern does just force a function expression and it should encapsulate the whole thing for a better readability.

jAndy
  • 231,737
  • 57
  • 305
  • 359
  • Using `+` or `-` instead of `!` can cause problems. Consider `var x = 42 /* line break but no semicolon */ !function(){...}()`. If you replace the `!` with `+` it becomes a binary operator and the result of the function call becomes part of the value of `x`. – Mike Samuel Feb 03 '12 at 15:14
  • @Mike: And that's why people should use semicolons. :P Semicolon insertion was one of the worst ideas to ever make it into a real programming language. If someone takes advantage of it, i pretty much assume they've never written any serious amount of JS code. – cHao Feb 03 '12 at 15:23
  • @cHao, People forget semicolons, so I'm just suggesting sticking to idioms that minimize the chance of confusion. – Mike Samuel Feb 03 '12 at 15:26
  • @MikeSamuel: thanks for the comment. Tho, I was just saying there are other characters which do the same trick. – jAndy Feb 03 '12 at 15:28
  • @jAndy, I agree. I'm just pointing out that there is a reason to prefer one to the others. – Mike Samuel Feb 03 '12 at 15:35
  • I'm pretty agnostic about which version to use, but have got in the habit of using the second one (mainly because jQuery does) – wheresrhys Feb 03 '12 at 15:39
2

The first example works for exactly the same reason the second example works. There's no real difference. This also works:

!function() { ... } ();

So does this:

var _dont_care_ = function() { ... } ();

The key is to arrange for the function keyword to appear in the statement at a point where the parser knows that it cannot be the start of a function declaration statement. In such cases, the function keyword must be instantiating a function object as a value in an expression.

Statements in JavaScript other than expression statements start with keywords (leave labels aside for the moment). Inside any statement that doesn't start with the function keyword (going out on a limb here), the only thing that function can mean is the instantiation of a function object value.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • So the closing ) kinda isn't needed other than to make the expression syntactically correct. Weird stuff. – wheresrhys Feb 03 '12 at 15:35
  • Yes exactly. Basically you just have to get things to the point where the parser knows that the `function` keyword isn't starting its own statement. So for example if you wanted you could use a "naked" function expression in one of the expressions of a `for` loop header, because a function definition can't happen there. – Pointy Feb 03 '12 at 15:59