Question: Does operand order really matter when evaluating equality or identity in JavaScript?
In code, (0 == value)faster or more correct than (value == 0)? (Note that this question is equally valid for the identity operator,. ===)
Since both equality and identity operators are commutative, I do not believe that the order of the operands should matter in the performance of the evaluation, unless there is any literal inherent in the left element in the calculation of the equality algorithm itself. The only reason I am surprised is that I recently used the Google Closure Compiler to collapse some JavaScript and noticed that
if (array.length == 0 && typeof length === 'number') {
was compiled for
if(0 == b.length && "number" === typeof c) {.
In both equality expressions: one free and one strict-Closure changed the order of my operands by placing the Number literal and string literal in the left parts of their corresponding expressions.
I was curious.
I read the "Equality Operators" section of the ECMAScript 5.1 Language Specification (Section 11.9, pp. 80-82) and found that, although equality algorithms begin first by examining left operands, there is no indication that it is faster or better to use a literal as this operand.
Is there something about ECMAScript type validation that makes literal validation optimal? Could this be some optimization in the Closure compiler? Or, perhaps, the implementation detail in an older version of the ECMAScript equality algorithm, which was nullified in this new version of the specification?