IIFE Parentheses #21

jcutrell · 2012-11-08T15:50:31Z

Could this:

(function() {
  console.log('Welcome to the Internet. Please follow me.');
})();

Be this? :

// Crockford's preference - parens on the inside
(function() {
  console.log('Welcome to the Internet. Please follow me.');
}());

reissbaker · 2012-11-08T19:56:13Z

For modules we've decided on this:

!function() {
  console.log('Welcome to the Internet. Please follow me.');
}();

...But I have no particular preference on where parens should go for IIFEs that aren't also modules. Usually they're not very useful -- if it needs to be hidden, make it its own module -- but in the cases where they are it doesn't really matter to me. Both seem equally readable.

Is there enough of a difference to make this worth codifying?

hshoff · 2012-11-08T20:38:50Z

If you don't care about the return value of the IIFE, it could also be any of the following:

!function(){}();  // => true
~function(){}(); // => -1
+function(){}(); // => NaN
-function(){}();  // => NaN

Let's explore this a bit more.

// module1.js
(function() {
  console.log('module1');
})();

// module2.js
(function() {
  console.log('module2');
})();

// production.min.js
(function(){console.log('module1');})();(function(){console.log('module2');})();
// => module1
// => module2

// crockford production.min.js
(function(){console.log('module1');}());(function(){console.log('module2');}());
// => module1
// => module2

Both work the same. It starts to get interesting when one of the modules is missing a trailing semicolon:

// problem
(function(){console.log('module1');})()(function(){console.log('module2');})();
// => module1
// => TypeError: undefined is not a function

// crockford problem
(function(){console.log('module1');}())(function(){console.log('module2');}());
// => module1
// => module2
// => TypeError: undefined is not a function

With a missing semicolon, each set of parens is trying to immediately-invoke the preceding expression. That would be the return value of the preceding IIFE.

(function(){ return undefined; })()();
// => TypeError: undefined is not a function

// equivalent
(undefined)();

(function(){ return undefined; }())(); // crockford
// => TypeError: undefined is not a function

// equivalent
(undefined());

So the difference is when the TypeError happens. Let's check out what the arguments are up to. Note that console.log() returns undefined:

// new module1.js
(function() {
  console.log('module1');

  // return a function that logs it's
  // arguments when invoked
  return function(){
    console.log(arguments);
  };
})()

// new production.js
// unminified problem for readability
(function() {
  console.log('module1');

  // return a function that logs it's
  // arguments when invoked
  return function(){
    console.log(arguments);
  };
})()(function() {
  console.log('module2');
})();
// => module1
// => [function() {
//      console.log('module2');
//    }]
// => TypeError: undefined is not a function

// the first step is to invoke the first module
(function(){console.log('module1');return function(){console.log(arguments)};})()
// => module1

// then it invokes the return value
// with module2 as arguments
(function(){ console.log(arguments) })(function() {console.log('module2');});
// => [function() {
//      console.log('module2');
//    }]

// then it tries to invoke the return value.
// console.log returns undefined so:
(undefined)();
// => TypeError: undefined is not a function

Now let's do that same example with the crockford way:

// new crockford module1.js
(function(){
  console.log('module1');

  // return a function that logs it's
  // arguments when invoked
  return function(){
    console.log(arguments);
  };
}())

// new production.js
// unminified problem for readability
(function(){
  console.log('module1');

  // return a function that logs it's
  // arguments when invoked
  return function(){
    console.log(arguments);
  };
}())(function(){
  console.log('module2');
}());
// => module1
// => module2
// => [undefined]

But wait, there's no TypeError here...

// it invokes module1
(function(){ console.log('module1'); return function(){ console.log(arguments); };}())
// => module1

//it invokes module2
(function(){ console.log('module2'); }());
// => module2

// equivalent
(function(){ console.log(arguments); })(undefined)
// => [undefined]

There's no TypeError because of the returned function. The returned function that logs the arguments is then getting invoked with the return value of module2, which is undefined.
With that understanding, let's go back to the original example, where there was a TypeError:

// crockford problem
(function(){console.log('module1');}())(function(){console.log('module2');}());
// => module1
// => module2
// => TypeError: undefined is not a function

// it invokes module1
(function(){ console.log('module1'); }())
// => module1

//it invokes module2
(function(){ console.log('module2'); }());
// => module2

// equivalent
(undefined(undefined))
// => TypeError: undefined is not a function

Conclusion
The (function{})(); and (function(){}()); IIFEs can act differently in the missing semicolon situation.

Use linter or a tool to make sure modules aren't missing trailing semicolons when working on modules.

To be extra safe add a leading semicolon to the IIFE:

// module1.js
;(function() {
  console.log('module1');
})()

// crockford module1.js
;(function(){
  console.log('module1');
}())

// module2.js
;(function() {
  console.log('module2');
})();

// crockford module2.js
;(function() {
  console.log('module2');
}());

// production.min.js
;(function(){ console.log('module1'); })();(function(){ console.log('module2'); })();
// => module1
// => module2

// crockford production.min.js
;(function(){ console.log('module1'); }());(function(){ console.log('module2'); }());
// => module1
// => module2

Hope that helps!

jcutrell · 2012-11-08T21:11:28Z

A fantastically thorough explanation.

egonyuri · 2012-11-16T10:31:51Z

Incredible explanation.

mikejoyceio · 2015-03-22T11:31:01Z

Great explanation. Thanks.

jaan · 2015-03-22T20:31:33Z

Good Explanation @hshoff

freeethy · 2015-05-06T01:32:17Z

Great explanation @hshoff . Thanks.

…de section. There was lots of discussion [here](#21 (comment)), but now that we have both a modern build system and an eslint rule requiring terminating semicolons, the concerns with the “crockford” style no longer apply.

…de section. There was lots of discussion [here](airbnb#21 (comment)), but now that we have both a modern build system and an eslint rule requiring terminating semicolons, the concerns with the “crockford” style no longer apply.

xiehongyang · 2016-04-21T07:15:09Z

Cool! help me a lot

…de section. There was lots of discussion [here](airbnb#21 (comment)), but now that we have both a modern build system and an eslint rule requiring terminating semicolons, the concerns with the “crockford” style no longer apply.

…de section. There was lots of discussion [here](airbnb/javascript#21 (comment)), but now that we have both a modern build system and an eslint rule requiring terminating semicolons, the concerns with the “crockford” style no longer apply.

hshoff closed this as completed Nov 15, 2012

hshoff mentioned this issue Nov 13, 2013

remove duplicate content #104

Closed

hshoff mentioned this issue Jan 1, 2015

Move generated parenthesis for IIFE into the parens #225

Closed

joeyparrish mentioned this issue Apr 10, 2020

Update closing parens wrapped in parentheses shaka-project/shaka-player#2495

Closed

geraldvillorente mentioned this issue Oct 26, 2023

[Snyk] Upgrade strip-json-comments from 1.0.2 to 1.0.4 geraldvillorente/javascript#5

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IIFE Parentheses #21

IIFE Parentheses #21

jcutrell commented Nov 8, 2012

reissbaker commented Nov 8, 2012

hshoff commented Nov 8, 2012

jcutrell commented Nov 8, 2012

egonyuri commented Nov 16, 2012

mikejoyceio commented Mar 22, 2015

jaan commented Mar 22, 2015

freeethy commented May 6, 2015

xiehongyang commented Apr 21, 2016

IIFE Parentheses #21

IIFE Parentheses #21

Comments

jcutrell commented Nov 8, 2012

reissbaker commented Nov 8, 2012

hshoff commented Nov 8, 2012

jcutrell commented Nov 8, 2012

egonyuri commented Nov 16, 2012

mikejoyceio commented Mar 22, 2015

jaan commented Mar 22, 2015

freeethy commented May 6, 2015

xiehongyang commented Apr 21, 2016