5

I was looking over one of the minified js files generated by closure. I found that wherever I'm checking for equality between a variable and string like,

a == "13" || a == "40"

closure replaces it with 

"13" == a || "40" == a

Why is this modification done? Is there some performance advantage here?

Jophin Joseph
  • 2,864
  • 4
  • 27
  • 40

2 Answers2

9

This is done as for a minor gzip compression advantage. If you have "x == 1" and "1 == x" the compiler switches it to "1 == x" in both cases and you get more regular code that compresses better. The win is so minor, that I've considered deleting the code and saving the cpu cycles, but it is on for now. It has nothing to do with preventing programmer errors as it will never switch "x = 2" into "2 = x" as that would change the meaning of the program.

John
  • 5,443
  • 15
  • 21
  • 1
    Makes sense. OP (@user843241) should change this to accepted answer. I'd delete my own answer but I don't know if that would be kosher. Although just for the record, Yoda Conditions never say anything about the order of operands on assignment; of course you would never change "x = 2" into "2 = x". Yoda Conditions are about order of operands on equality comparison only. – Ben Lee Feb 15 '12 at 16:17
5

[UPDATE: See @John's answer, it makes more sense as to why a js minifier would do this, and should be the accepted answer]

As a general concept, this is to avoid programmer error. If you were modifying the code manually and put the variable first and constant second, it's possible to accidentally type:

a == '40' || a = '13'

Oops! We just set a to '13' instead of comparing. By putting the constant on the left, we avoid this possibility:

'40' == a || '13' = a

Will throw an exception because you can't put a constant string on the left hand of an assignment operation.

So in some schools of thought, it's best practice to always put the constant on the left when doing equality comparison against a constant. Looks like closure follows that practice.

These are called "yoda conditions".

Note that my personal preference is to actually to just put the constant on the right in most cases, because the code tends to read better, so I don't think the tradeoff is good enough. But I see the logic behind yoda conditions.

Ben Lee
  • 52,489
  • 13
  • 125
  • 145
  • That doesn't explain why a compressor would do it though. OT: Did they actually delete the [thread on Yoda conditions](http://webcache.googleusercontent.com/search?q=cache:stackoverflow.com/questions/2349378/new-programming-jargon-you-coined+jargon+coined)?! – user123444555621 Feb 13 '12 at 07:13
  • The compressor uses best practices wherever possible, just because it can. (Offchance that someone edits the minified version maybe?) – Ben Lee Feb 13 '12 at 07:17
  • Also, I wasn't aware of that thread about yoda conditions. I've just heard this described that way before. – Ben Lee Feb 13 '12 at 07:18
  • In the docs here (http://code.google.com/speed/articles/compressing-javascript.html), they mention that in addition to minification the compiler is opinionated about code practices and it can even warn you about things. In this case, it looks like it just silently converts these comparisons to yoda format. – Ben Lee Feb 13 '12 at 07:20
  • @Pumbaa80, I posted a meta topic asking if it's possible to revive that thread you pointed out. http://meta.stackexchange.com/questions/122154/can-we-revive-deleted-content-that-does-not-follow-the-guidelines-but-nonetheles – Ben Lee Feb 13 '12 at 07:47
  • This is actually wrong, because `a = 3` will NOT get rewritten to `3 = a` because it's an assignment. Garbage in, garbage out basically :) – Ja͢ck Dec 04 '12 at 11:50
  • @Jack, I don't see how that's relevant, or what's "wrong" -- assignment has nothing to do with Yoda conditions. As I mentioned in my comment to the other answer (which I up-voted and believe should be the accepted answer), I wrote: "Just for the record, Yoda Conditions never say anything about the order of operands on assignment; of course you would never change 'x = 2' into '2 = x'. Yoda Conditions are about order of operands on equality comparison only." – Ben Lee Dec 04 '12 at 16:06
  • If it's still unclear, it prevents programmer error by forcing a crash-and-burn error condition when the programmer accidentally types a single "=" instead of a "==" when intending to compare, when a constant is on the left. With a constant on the right, the program still has an error but doesn't necessarily crash-and-burn, and can cause really hard-to-track-down bugs because it's easy to not notice this when looking for the bug. – Ben Lee Dec 04 '12 at 16:14
  • Thanks for updating the answer. I understand the contents of your answer and that's why I didn't dv it, but anyone who stumbles onto this question would otherwise think closure compiler does it because of a yoda affection :) – Ja͢ck Dec 04 '12 at 22:24