Why is var x = x = x || {} more thorough than var x = x || {}?

Question

In my endeavour to write clean Javascript code as a beginner, I was recently reading this article about namespacing in JavaScript when I stumbled upon this paragraph:

The code at the very top of the next sample demonstrates the different ways in which you can check to see if a variable (object namespace) already exists before defining it. You'll commonly see developers using Option 1, however Options 3 and 5 may be considered more thorough and Option 4 is considered a good best-practice.
// This doesn't check for existence of 'myApplication' in
// the global namespace. Bad practice as you can easily
// clobber an existing variable/namespace with the same name
var myApplication = {};

/*
The following options *do* check for variable/namespace existence.
If already defined, we use that instance, otherwise we assign a new
object literal to myApplication.

Option 1: var myApplication = myApplication || {};
Option 2  if(!MyApplication) MyApplication = {};
Option 3: var myApplication = myApplication = myApplication || {}
Option 4: myApplication || (myApplication = {});
Option 5: var myApplication = myApplication === undefined ? {} : myApplication;

*/

Option 1 is certainly the one I have seen used most of the time, and I understand it well.

Option 2 is fine but seems to lack a var myApplication beforehand or a if(!window.myApplication) otherwise if myApplication is not in the global scope the condition if(!myApplication) would throw an error, wouldn't it?

Option 3 is the one I have trouble with: my understanding is that the myApplication = myApplication is executed first, with myApplication in the global scope (due to the var at the begining). My problem is that I can't think of a case where this option does anything more than option 1.

Option 4 in my eyes would have been better written window.myApplication || (myApplication = {}) to avoid throwing an error if myApplication is not in the global scope.

Option 5 is excluding the false-y values other than undefined but is it a good idea? If myApplication is say an empty string, the rest of the code is likely to fail, isn't it?

Would someone be able to shed some light on the differences between the different options and in particular explain why option 3 is described as more thorough?

I imagine some of the answer depends on the disuse of `'use strict'`. When you say option 1 will throw an error because the middle declaration doesn't have `var`, that is only true if you use `'use strict'`. — trysis, Apr 16 '18 at 15:33
@trysis Option 1 is fine, do you mean option 3? I don't understand... — Jacques Gaudin, Apr 16 '18 at 15:48
@trysis: Strict mode has no effect on any of the options listed. The closest relevant change strict mode makes is assigning to an undeclared identifier becomes an error instead of what I call [*the Horror of Implicit Globals*](http://blog.niftysnippets.org/2008/03/horror-of-implicit-globals.html). But all of the above either declare the identifier (1, 3, 5), or attempt to *evaluate* a possibly-undeclared identifier prior to assigning to it (2, 4), which will fail if the identifier is undeclared, even in loose mode. (Option 2 would relate to strict mode if it used `typeof`, but it doesn't.) — T.J. Crowder, Apr 16 '18 at 17:20
Why would you want to do this? If I were you, I would drop `var` and global properties altogether and I'd move to `let` and modules. — m93a, Apr 16 '18 at 20:01
@m93a The point is to understand what I read, I know that modules are the way to go nowadays but learning the basics of the language is where I am at present :-) — Jacques Gaudin, Apr 16 '18 at 20:37
I meant options 1, 3 & 5. I didn't realize errors would be thrown even in loose mode, I guess I'm not as knowledgeable about old JavaScript as I would like to be. — trysis, Apr 17 '18 at 02:12

T.J. Crowder · Accepted Answer · 2018-04-16T08:22:13.367

If the article claims Option 3 is "more thorough," it's incorrect. There's no point to the middle of that assignment chain at all.

Would someone be able to shed some light on the differences between the different options and in particular explain why option 3 is described as more thorough?

First, a caveat: Here in 2018, you probably don't want to use any of these. Instead, use proper modules, either via one of the various module definition syntaxes (AMD, CommonJS, RequireJS) with a relevant tool, or via ES2015+ modules with import and export (and probably a relevant tool such as Babel and perhaps Webpack or Browserify, although current versions of Chrome, Safari, and Edge support modules natively, and Firefox does as well currently behind a flag).

Why is var x = x = x || {} more thorough than var x = x || {}?

It isn't.

Option 2 is fine but seems to lack a var myApplication beforehand or a if(!window.myApplication) otherwise if myApplication is not in the global scope the condition if(!myApplication) would throw an error, wouldn't it?

Yes. (Assuming that production occurs at global scope. if it's not at a global scope and there's an in-scope myApplication anywhere in the current scope chain, it won't throw because myApplication won't be an unresolved symbol.)

Option 3 is the one I have trouble with: my understanding is that the myApplication = myApplication is executed first, with myApplication in the global scope (due to the var at the begining). My problem is that I can't think of a case where this option does anything more than option 1.

No, if you have

var myApplication = myApplication = myApplication || {}

this is the order in which things happen:

var myApplication creates the global if it doesn't already exist, leaves it untouched if it does
myApplication || {} is evaluated and takes either the value in myApplication (if it's truthy) or {} (if not); let's call that value1
myApplication = value1 (the one in the middle) is performed, and the result is value1
myApplication = value1 (the one on the left) is performed again for no good reason

Option 4 in my eyes would have been better written window.myApplication || (myApplication = {}) to avoid throwing an error if myApplication is not in the global scope.

Indeed.

Option 5 is excluding the false-y values other than undefined but is it a good idea? If myApplication is say an empty string, the rest of the code is likely to fail, isn't it?

Yes.

Thanks for a thorough run through all these options (no pun intended). This answer is illuminating. RequireJS is the next step but for now I am trying to build a sound knowledge of the language. — Jacques Gaudin, Apr 16 '18 at 09:14
My best guess is that the original author thinks the order of operations of Option 3 is `var myApp = ((myApp = myApp) || {});` (which still wouldn't make sense anyway) — Izkata, Apr 16 '18 at 21:52
@JacquesGaudin I fail to see the pun in your comment. Would you mind explaining it, please? — ijmacd, Apr 17 '18 at 01:14
@ijmacd clue: look thoroughly at this comment and you will find out. — Jacques Gaudin, Apr 17 '18 at 20:48

Why is var x = x = x || {} more thorough than var x = x || {}?

1 Answers1