Javascript Catches And Pitfalls – part1 (equality and comparisons)

Javascript is a programming language originally written in 10 days, buy a chap named Brendan Eich for the Netscape Corporation. However brilliant, Brendan is still just a human, so you’d guess that Javascript was not without bugs and corks. Although a lot has changed since then, a solid number of JS specific “head scratchers” lives on. This post is the first one in a series of posts I plan on writing over the next few weeks on famous, as well as relatively unknown, pitfalls specific to the JS language.

This first post will be all about equality and comparisons. If you’re not experienced developer you might think that a whole post on equality and comparisons pitfalls may be excessive, but by the end of this text you’ll most probably change your mind. Let me start…

JavaScript has two different ways of comparing the values of objects for equality.

The Equality Operator

The equality operator consists of two equal signs: ==

JavaScript is a “weakly typed” programming language. This means that the equality operator coerces types in order to compare them.

The above table shows the results of the type coercion, and it is the main reason why the use of == is widely regarded as bad practice, unless you’re sure you know what  you’re doing. These complicated conversion rules are the main reasons for number of bugs that are really hard to track down.

On top of that, type coercion causes a performance impact (when for example string is being converted to a number before it can be compared to another number)

The Strict Equality Operator

The strict equality operator consists of three equal signs: ===.

The main difference between the two is in the fact that strict equality operator does not perform type coercion between the operands

The above results are a lot clearer and allow for early breakage of code. This hardens code to a certain degree and also gives performance improvements in case the operands are of different types.

Comparing Objects

Although both == and === are equality operators, they do not behave the same when at least one of their operands is an Object.

In that case, both operands will be actually compared for identity, and not for equality, meaning the operator will be checking if objects compared are actually the same instance (similar to how C programming language performs pointer comparisons, for example).

Number, String and Boolean objects

Javascript, apart from having number, string, and boolean types as primitives, also features these types as objects. Considering the above section (Comparing objects), if you don’t know what you’re doing, comparisons between those can cause you a lot of pain. Let’s see another example.

Do not use number, string, and boolean objects unless you know what you’re doing and have a particular reason for it.

Comparing the NaN object

This one will be short… NaN never, ever, ever, ever, ever equals anything!!! Even

will be resolved to false.

Javascript equality table

Someone went through significant effort to summarize all Javascript comparisons in one place, in a format that’s easy to understand and I’m ever greatfull for that. If you do Javascript, you should put this link into your bookmarks.

Here’s the link once again, I think it’s that important.

https://dorey.github.io/JavaScript-Equality-Table/

In Conclusion

It is highly recommended to only use the strict equality operator. In cases where types need to be coerced, it should be done explicitly and not left to the language’s complicated coercion rules.

NaN never ever equals to anything, that includes NaN.

If you’re experiencing a bug that’s really hard to track down, consider reviewing your comparisons and match them against this table.

One thought on “Javascript Catches And Pitfalls – part1 (equality and comparisons)

Leave a Reply

Your email address will not be published. Required fields are marked *