We know many comparison operators from maths.
- Greater/less than:
a > b,
a < b.
- Greater/less than or equals:
a >= b,
a <= b.
a == b, please note the double equality sign
==means the equality test, while a single one
a = bmeans an assignment.
- Not equals: In maths the notation is
a != b.
Boolean is the result
All comparison operators return a boolean value:
true– means “yes”, “correct” or “the truth”.
false– means “no”, “wrong” or “not the truth”.
A comparison result can be assigned to a variable, just like any value:
In other words, strings are compared letter-by-letter.
The algorithm to compare two strings is simple:
- Compare the first character of both strings.
- If the first character from the first string is greater (or less) than the other string’s, then the first string is greater (or less) than the second. We’re done.
- Otherwise, if both strings’ first characters are the same, compare the second characters the same way.
- Repeat until the end of either string.
- If both strings end at the same length, then they are equal. Otherwise, the longer string is greater.
In the first example above, the comparison
'Z' > 'A' gets to a result at the first step.
The second comparison
'Glee' needs more steps as strings are compared character-by-character:
Gis the same as
lis the same as
ois greater than
e. Stop here. The first string is greater.
The comparison algorithm given above is roughly equivalent to the one used in dictionaries or phone books, but it’s not exactly the same.
For instance, case matters. A capital letter
"A" is not equal to the lowercase
"a". Which one is greater? The lowercase
Comparison of different types
For boolean values,
It is possible that at the same time:
- Two values are equal.
- One of them is
trueas a boolean and the other one is
falseas a boolean.
0), while the explicit
Boolean conversion uses another set of rules.
A regular equality check
== has a problem. It cannot differentiate
The same thing happens with an empty string:
This happens because operands of different types are converted to numbers by the equality operator
==. An empty string, just like
false, becomes a zero.
What to do if we’d like to differentiate
A strict equality operator
=== checks the equality without type conversion.
In other words, if
b are of different types, then
a === b immediately returns
false without an attempt to convert them.
Let’s try it:
There is also a “strict non-equality” operator
!== analogous to
The strict equality operator is a bit longer to write, but makes it obvious what’s going on and leaves less room for errors.
Comparison with null and undefined
There’s a non-intuitive behavior when
undefined are compared to other values.
- For a strict equality check
These values are different, because each of them is a different type.
- For a non-strict check
There’s a special rule. These two are a “sweet couple”: they equal each other (in the sense of
==), but not any other value.
- For maths and other comparisons
< > <= >=
null/undefinedare converted to numbers:
Now let’s see some funny things that happen when we apply these rules. And, what’s more important, how to not fall into a trap with them.
Strange result: null vs 0
null with a zero:
Mathematically, that’s strange. The last result states that "
null is greater than or equal to zero", so in one of the comparisons above it must be
true, but they are both false.
The reason is that an equality check
== and comparisons
> < >= <= work differently. Comparisons convert
null to a number, treating it as
0. That’s why (3)
null >= 0 is true and (1)
null > 0 is false.
On the other hand, the equality check
null is defined such that, without any conversions, they equal each other and don’t equal anything else. That’s why (2)
null == 0 is false.
An incomparable undefined
undefined shouldn’t be compared to other values:
Why does it dislike zero so much? Always false!
We get these results because:
undefinedgets converted to
NaNis a special numeric value which returns
falsefor all comparisons.
- The equality check
undefined, and no other value.
Why did we go over these examples? Should we remember these peculiarities all the time? Well, not really. Actually, these tricky things will gradually become familiar over time, but there’s a solid way to avoid problems with them:
- Treat any comparison with
undefined/nullexcept the strict equality
===with exceptional care.
- Don’t use comparisons
>= > < <=with a variable which may be
null/undefined, unless you’re really sure of what you’re doing. If a variable can have these values, check for them separately.
- Comparison operators return a boolean value.
- Strings are compared letter-by-letter in the “dictionary” order.
- When values of different types are compared, they get converted to numbers (with the exclusion of a strict equality check).
- The values
==each other and do not equal any other value.
- Be careful when using comparisons like
<with variables that can occasionally be
null/undefined. Checking for
null/undefinedseparately is a good idea.
<code>tag, for several lines – wrap them in
<pre>tag, for more than 10 lines – use a sandbox (plnkr, jsbin, codepen…)