`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)
    
    

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.