3

So I use the Google Closure Compiler to minify my JavaScript before using it in production. Today, I paid attention to how it minifies and optimizes(?) the code and realized this trend:

Compiling the code below :

function b(a) {
    if ( a == null ) {
       console.log('ohai');
    }
}

resulted in an optimization in the comparison expression where the literal is moved to the left and the variable to the right. As in 

function b(a){null==a&&console.log("ohai")}

(Btw, it subsitutes single quotes for double quotes.) The expression remains the same if the other operand is an object. Why is moving the literal to the left of the operator an optimization of the expression?

Yaw Boakye
  • 9,462
  • 1
  • 15
  • 25
  • My guess is that this isn't a performance optimization as much as a readability optimization. Putting the null up front means that even in very long conditionals, it is clear it is a test for null (a common pattern). Any sensible definition of `==` (I'm looking at you PHP) should be such that it is commutative (`x == y <=> y == x`). – Two-Bit Alchemist Mar 24 '14 at 20:00
  • 6
    Keeping a consistent argument order creates longer common strings, which can be gzipped better. http://stackoverflow.com/questions/13701205/why-does-google-closure-swap-arguments/13702046 – DCoder Mar 24 '14 at 20:00
  • @Two-BitAlchemist Readability will not be the argument here, the closure compiler is also minifying the code, thus removing any unnecessary whitespace, renaming variables to be as short as possible, etc. It greatly *reduces* readability. For example, look at [minified JQuery](http://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js). Not sure if it is minified using Google's tool, but the idea is the same. – Daniël Knippers Mar 24 '14 at 20:18
  • Like I said it was a guess. I think @DCoder is probably right. I assumed maybe it was there whether or not you had the 'minify' option turned on, y'know? :P – Two-Bit Alchemist Mar 24 '14 at 20:26

1 Answers1

0

There's no optimisation improvement (EDIT: possibly a hasty statement, DCoder's comment for e.g. is valid), but you could make the argument that it's just prudent practice.

For example, a programmer might accidentally use a single = instead of == - resulting in assignment instead of an equality check.

The following code would silently evaluate with no error:

var a = null;
function b(a){a=null&&console.log("ohai")} // notice the single =
b(a); // nothing

However, the way google does it, it produces an error in the console (tested in Chrome):

var a = null;
function b(a){null=a&&console.log("ohai")} // notice the single =
b(a); // produces error Uncaught ReferenceError: Invalid left-hand side in assignment

Hence, using null as the left-hand side makes these kind of user errors easier to spot.

Rhys
  • 1,330
  • 1
  • 10
  • 22
  • It's a *compiler output*, so nothing what programmer could do wrong :-) – Bergi Mar 24 '14 at 20:18
  • @Bergi that's why i said it was prudent practice :) when you've got a choice between two seemingly inconsequential options, you pick the best practice one, even if it isn't going to be touched by humans. Can't claim that was necessarily the original design thought, but it's valid, nonetheless. – Rhys Mar 24 '14 at 20:37
  • The compiler can see your code during compilation and already emits a lot of warnings about problems at that time. Why should it be silent about this particular error and instead create this contraption that will only blow up at runtime? (Also, if you try compiling your code snippet at http://closure-compiler.appspot.com/home, it simply throws away the whole statement rather than doing what you suggested...) – DCoder Mar 25 '14 at 05:27