Let's talk about equality

Equality has been a major topic of discussion over the last few weeks. Whenever this topic comes up, I am always suprised how limited many people’s knowledge about true equality is. Relax everyone, I am talking about equality operators in JavaScript, and not the topic of national discussion recently.

Thinking back to some interviews I have been a part of recently, it became extremely obvious how little most Front End Web Developers know about the JavaScript equaltiy operators. You got that right, I said “operators” because there are two operators that test for equality between two objects, == and ===.

##==

This equality operator, called “double equals” for obvious reasons is the one that you run across frequently in many languages other than JavaScript, and it the only equality operator those other languages utilize. In JavaScript, this equality operator has a two step process that it takes to determine whether the values are equal. It first will check to see if the values are of the same data type. If they are both the same data type, it will do a simple comparison to see if the values are the same, returning true if they are, and false if they are not the same. However, if the values are not of the same data type, the JavaScript engine will attempt to convert the values into matching data types. If it is unable to do so, it returns false. If it is able to convert the values into matching data types, it will then check to see whether the values are equal, returning true if they are and false if they are not.

##===

This equality operator, called “triple equals” for obvious reasons is the one that you mainly will run across in JavaScript. Whereas the double equals tries to take the values and convert them into matching data types before comparing the values, the triple equals requires that the values be of the same data type as well as have the same value. This is important because it allows developers to perform basic sanity checks on the data that is being used for comparisons. "1" == 1 would result in true, whereas "1" === 1 would result in false. While this is a simple scenario that may not make much different either way, there are situations where this could have unintended consequences. For example, does "100" == true return true or false? If you are used to C++ or other related languages, you might expect it to return true since in those languages, any positive integer can represent true, and any negative integer can represent false, however, in JavaScript, it would return false.

There are many other scenarios where you may get unintended results with the == equality operator, so the general rule is that you should always use the === equality operator and use explicit conversions in your code to make sure that the values are of the same data type. This eliminates the strange variations in browsers and how they interpret their ability to convert data types and values for the == operator.

comments powered by Disqus

Related Posts

Always Use Automated Integration Testing

QA or Quality Assurance of a software project is often the area of software development that is most neglected. Typically developers avoid software testing like their lives depended on it. While a basic level of testing is required for a single scenario to validate that your code “works”, the level of testing that is required to ensure that all users have a good user experience across all targeted platforms is something that a developer seems to think is beneath them.

Read More

Parallax Background Scrolling on Internet Explorer is Not Smooth

One of the pleasures of working on a website that is using some of the latest technologies is that you often run into strange compatability issues that only affect one browser or another, and many of the forums have little to no information about how to properly address the issues. Parallax scrolling is a technique that has been around for a while now, highlighted by Apple’s own iPhone 5s card-esque scrolling on their homepage, among others.

Read More

The Easiest Way to Create A Solution That Works

The easiest way to create a solution that works…is to do it right the first time. Yes, this is a bit of a cop-out, but it turns out to be an important factor to keep in mind when you are tempted to come up with a quick and dirty solution for a problem that does not follow established best practices and is likely to have code quality issues later. I have run across many sections of code that I or other developers have written in the past that we thought were “good enough” at the time it was written, yet, I was revisiting the code because we discovered a bug in it.

Read More