`x || (x = y)` pattern for using an incoming value otherwise using some default

gistfile1.js

// from https://twitter.com/#!/LeaVerou/status/16613276313980929


// this pattern below is common for using an incoming value otherwise using some default.

/* Bad:    */  x = x ? x : y; // simple ternary. 
                              // if x is truthy lets use it.

/* Better: */  x = x || y;    // logical OR. 
                              // you could string a bunch of these easily to grab the first non-falsy value: 
                              //   x = x || y || z || a;
                              
/* Best:   */  x || (x = y);  // right-hand assignment!
                              // done without the parens this would throw a syntax error.
                              // if x is truthy we don't even need to do the assigment, 
                              //   so the logical OR will bypass it.

// jslint especially hates that last one. big surprise. 



// and of course, if x is intentionally supposed to be 0, false, or '' 
//   then you're fucked and you'll have to do something nasty like:
    x = (x !== undefined) ? x : y; // yuck. (parens optional)
    
    

Everyday that Crockford sneezes 2 developers that don't use JSLint become unemployed #crockfordfacts

Now, seriously, I don't really like when over optimization steps in the way of maintainability of my code. Paul, I think this is the kind of stuff Rebeca would have something to comment about on yayQuery =)

okay i do agree with that.

:)

maybe it shoulda been.. "noob / pro / cool guy"

The right-hand assignment is a quite clever way to coax an undefined x into a default, but other than that, the pattern is just a party trick— and it's merely a special case the another more general party trick we love to play with || and &&

Though for setting a default, I do like the looks of it over x = x || y;

For benchmarks, please refer to the good old http://jsperf.com/conditional-assignment. (Someone else made a different jsPerf test case with inaccurate tests in it, so don’t use that!)

@mathiasbynens Great to see this performance tests!
For me, the best scenario would be that my JavaScript compressor would convert this kind of stuff always to the most performant way.
In fact, could the minification tools out there be changing the performance of the code? They do change some if/else statements to ternarys, right?

@irae Closure Compiler is known to tweak the code, for example by switching between for and while loops. YUI Compressor doesn’t seem to alter the code in any way (except for removing redundant whitespace and semicolons, of course). I’m not sure about the other JS minifiers.