Deep JavaScript Foundations

# Double vs. Triple Equal

Check out a free preview of the full Deep JavaScript Foundations course:
The "Double vs. Triple Equal" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

## Kyle discusses that the double-equal operator allows coercion in a comparison while triple equal operator, ===, does not. Afterward, Kyle walks through some examples demonstrating how the result of these two operators can differ.

Get Unlimited Access Now

Transcript from the "Double vs. Triple Equal" Lesson

[00:00:00]
>> Kyle Simpson: So now let's turn our attention to double equals versus triple triple equals. Many people have asserted, well, I don't see any purpose to == and I've heard that there's these weird corner cases that could bite me, so I'm just gonna use === forever. Always, always use ===.

[00:00:15] Linters will tell you that, books will tell you that, speakers will tell you that, teachers will tell you that. I happen to be the only one, it seems, stands up and says, maybe we ought to use both. Maybe there are times double equals is useful, as matter of fact, I think there are some very important times when it's useful.

[00:00:33] So I'm gonna compare the usage of these two. How many of you have heard this before, double equals checks the value and triple equals checks the value and the type? Anybody heard that before? As the description for what's going on. This is the most common man, if you will, description for this.

[00:00:51] Unfortunately, it's false. That is not at all the difference between those two operators. How do I know? Cuz I read the spec. Turns out, the difference between them is the double equals allows coercion and the triple equals disallows coercion. They both test equality. One of them allows coercion to occur first and one of them doesn't.

[00:01:16] And just that one simple fact reframes this whole debate. It reframes this debate as a question of, in this particular comparison, would it be useful or helpful for me, or more readable for me, to allow coercion to occur? If so, use double equals. In this particular comparison, would a coercion be troublesome, would it be problematic for me?

[00:01:41] If so, don't allow coercion. Avoid the double equals and use triple equals instead. The question should not be which one is right and which one is wrong? What does Linter say? The question is, for this statement, for this comparison, which one is the more appropriate action, coercion or not?

[00:01:59] We've already established that coercion is useful, we've already established that coercion can sometimes make code more readable. So you just have to decide if this particular comparison could benefit from the coercion or not. Everybody with me?
>> Kyle Simpson: Here's the spec for the double equals, it happens to be referred to as the Abstract Equality Comparison algorithm.

[00:02:23] This is the entirety of them, that's really it. This thing that you've been taught as this black magic box that can't possibly learn, is ten lines long, and most of it is spec fluff, okay? You could spend ten minutes reading this and be an expert on this algorithm better than 99.99% of your peers.

[00:02:41] And that's all I did was read the spec, shocking as it sounds. It's actually pretty straightforward. Right here on the very first item, number 1, we see exactly what I was talking about, which is that it checks the type. Wait a minute, why is the double equals checking the type?

[00:03:04] Cuz it turns out both of them check the type. It's just that they differ on what they do with that information, okay?
>> Kyle Simpson: Now somebody was asking online about the null. You'll see items 2 and 3 specifically call out null and undefined. They say if one of them's null and the other one's undefined, or one of them's undefined and the other one's null, if that's the case, return true.

[00:03:26] In other words, make null and undefined coercively equal to each other, and to no other values in the language. That turns out to be a really useful fact, actually. One of my most favorite facts about JavaScript, because I don't like the confusion of having two different empty values, I find that to be frustrating.

[00:03:47] What this means is I can treat null and undefined as coercively equivalent. I don't have to have two empty values. Regardless of whether it's null or undefined, I can allow coercion to hide that unneccessary detail, thereby making my code simpler.
>> Kyle Simpson: I see some skeptical looks on faces, that's okay.

[00:04:10] You're gonna get a chance in a moment to work on an exercise where you get to practice this yourself. And remember I mentioned earlier, this algorithm prefers numeric comparison. Here's where we see that.
>> Kyle Simpson: If the type of one is a number and the type of the other is a string, make the one that's not a number into a number.

[00:04:30] We just see that over and over again. There is a default preference to compare numbers. That doesn't override the null and undefined as we saw but it does say if we have non-null non-undefined primitives, turn them into numbers cuz number comparison is more efficient. Weather or not it's more efficient, it's also a fact that once you learn will make this algorithm more predictable, even if you don't like the outcome, at least it's more predictable.

[00:05:02] You follow that? Even if you disagree with it, at least you move it out of the realm of being an unknown to being in the realm of being a known. I know what it's gonna do. It's gonna compare them as numbers.
>> Kyle Simpson: So here are some examples. I got an empty array and an empty string.

[00:05:24] And that should be some warning bells that tell me don't use ==, cuz here the coercion would be dangerous. Avoid line 3, do line 6 instead. Make the comparison with triple, okay? I got a 0 and an empty string on lines 10 and 11. Avoid double equals, that's a warning sign.

[00:05:45] Avoid double equals, use triple equals like line 14.
>> Kyle Simpson: But what about cases where it can be useful?
>> Kyle Simpson: How about this one? You start off with a value that may or may not be string 3 or the number 3, and you want to pass which ever one of those two it is.

[00:06:10] Your first option is line 2, which is to say, === 3 or ===, quote, 3. Now, there's no question that that line is more explicit. But when we compare that line to line 6, line 6 allows coercion to occur, where line 2 does not. So my question to you is, which one of those two lines is on the whole more readable?

[00:06:39] You make your own determination but I would argue that line 6 is more readable. Because for the purposes of that decision making, the actual underlying value type is not a relevant fact to me. The only thing that matters to me is that, it's one of the two 3s.

[00:06:59] And I'm allowing coercion to hide the rest of that unnecessary detail. Remember I said earlier that the most readable code is code I didn't have to read. I don't need to read two different comparisons when one comparison will suffice. And there is absolutely no corner cases here to be worried about.

[00:07:18] Cuz I know it is either going to be 3 or string 3, so it's totally safe for me to use a double equals and simplify my code.
>> Kyle Simpson: Now that's just one little micro example. Null and undefined are another example. Remember I said, null and undefined are coercively equal to each other.

[00:07:35] I can do a comparison check of ==null like line 7 and it will catch the case of null or undefined like line 2, but it will not catch any other corner cases. So I can either say, double equal to null or I can say triple equal to null, or triple equal to undefined.

[00:07:53] Do I really want to make it obvious to the the reader of my code that there is two different empty values to be concerned about? How about hide that unnecessary information. Now what I'm getting at here is that those are my decisions, they're my subjective decisions that that improves those comparisons.

[00:08:12] And these are just small little examples plucked out of much larger patterns. The only thing that I want you to do is to walk away from this discussion saying, I'm gonna think about it critically, that's it. I'm going to think about it critically and make those decisions. As opposed to, I'm just going to keep on doing the same thing I've always done because it doesn't matter.

[00:08:35] It does matter. The way we choose to express our code does matter. And understanding how to do the code is the first step to expressing it better.
>> Speaker 2: So, in this particular case, it comes down to style and the preference of the team really, rather than-
>> Kyle Simpson: I'm not sure I would totally label this as style but it definitely comes down to idiomatic decision for the team.

[00:09:04] Is the team willing to say that we communicate better by hiding unnecessary type information in these places, or is the team willing to say we wanna be explicit? If your team sits down and has a conversation about that and weighs the pros and cons. And you end up saying, we wanna be more explicit about it, you have my blessing.

[00:09:22] But if your team just says, well, that's what the Linter tells us. To me, that's not a sufficient standard. Does that help? I'm not telling you what to conclude, I'm just telling you that you should think about it and debate it.