CODEWITHSUNDEEP
javascriptgoogle-closure-compiler
Nathan
Nathan

Reputation: 1425

Does order of operands in equality matter? (e.g. 1 == x vs x == 1)

So I'm trying out the Google Closure Compiler and I've noticed that it switches all my equality parameters so that the variables are always on the right side of the comparison.

So now instead of typeof XMLHttpRequest=="undefined" I have "undefined"==typeof XMLHttpRequest and I have if(null!==a) instead of if(a!==null), just as some examples.

I know they accomplish the same thing, but it's just not the style I'm used to. Is there some sort of benefit that you get for having these switched? I can't see how there would be.

Can someone explain to me why the Closure Compiler decides to do this? Is it just a preference of whoever wrote that part of Closure?

Edit: To clarify, people are telling me why it might be considered good coding practice. That's fine, but this is after compilation. Is there a performance benefit or is the Closure Compiler just trying to prove a point?

Upvotes: 11

Views: 563

Answers (6)

John
John

Reputation: 5468

The compiler switches the order for a very simple reason: it compresses better with gzip. The compiler doesn't care a wit about improving comprehension or making it easier to edit. By switching the order common comparisons such as "if (x == null) ... if (y == null) ..." become "if (null == x) ... if (null == y) ..." Gzip finds "if (null ==" and is able to replace it with a single token. It isn't a big improvement, but it adds up in a large code base.

Upvotes: 10

Yuriy Vikulov
Yuriy Vikulov

Reputation: 2499

Just a cheap replacement of static analysis of particular case of common mistake/

Upvotes: 1

Tegiri Nenashi
Tegiri Nenashi

Reputation: 3086

My brain parses

if( x < y )

slightly faster than

if( y > x )

probably because real axis is always oriented from left to right, thus making condition easier to visualize.

However, in java it is more practical to write 

if( "string".equals(x) ) {...

as opposed to "more natural"

if( x.equals("string") ) {...

to eliminate any opportunity for NPE.

Upvotes: 1

Banjocat
Banjocat

Reputation: 382

The reason I know is is done to prevent

if (x = 5) { }

If you reverse it to 

if (5 = x) { }

You would get a compiler error.

But if you write it as

if (5 == x) { }

It will compile fine.

Upvotes: 3

alex
alex

Reputation: 490607

Yes, you can't assign to a constant, and == is easy to mistype (sometimes you may forget one, and use =).

For example, what's the difference between...

if (a == 1) { }

...and...

if (a = 1) { }

? The second one will always evaluate to true, not matter what the value of a.

If you flip the LHS and RHS, you can see the immediate benefit...

if (1 == a) { }

...will work as expected and...

if (1 = a) { }

...will fail, as you can't assign to a constant.

Upvotes: 3

John3136
John3136

Reputation: 29266

Commonly done in languages like C / C++ so you can't accidently do

if (a = null) {
    // sets a to null and everyone is happy.
    // but probably meant to check if a is null or not.
    // via (a == null)
}

if (null = a) {
    // won't compile
}

Upvotes: 12

Related Questions