Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In Javascript, the Good Parts, Douglas Crockford wrote:

JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:

'' == '0'           // false
0 == ''             // true
0 == '0'            // true

false == 'false'    // false
false == '0'        // true

false == undefined  // false
false == null       // false
null == undefined   // true

' \t\r\n ' == 0     // true

The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.

Given this unequivocal observation, is there ever a time when using == might actually be appropriate?

share|improve this question
1  
It makes sense in lots of places. Any time it's obvious you're comparing two things of the same type (this happens a lot in my experience), == vs === just comes down to preference. Other times you actually want abstract comparison (like the case you mention in your answer). Whether it's appropriate depends on conventions for any given project. –  Hey 7 hours ago
    
@Hey: That's a little vague. If it doesn't matter, then why not use === and eliminate any possibility of ambiguity? Also, Stack Exchange questions are never answered with a simple "yes" or "no," and I really doubt that it makes sense in a lot of places. –  Robert Harvey 5 hours ago
    
Crockford also recommends not using ++ or --. The argument there is the same; use += or -= instead to remove any possibility of ambiguity. You can probably guess how often projects follow those guidelines. Does that mean -- and ++ are never appropriate? I think it just means they are not appropriate for projects following that particular convention. –  Hey 3 hours ago
2  
Regarding "lots of places," in my experience the cases where it doesn't matter outnumber cases where it does. Your experience may be different; maybe we have experience with different kinds of projects. When I look at projects that use == by default, === stands out and lets me know something important is going on. –  Hey 3 hours ago
    
"Does using Javascript ever make sense?" No. –  Euphoric 6 mins ago

2 Answers 2

It turns out that jQuery uses the construct

if (someObj == null) {
  // do something
}

extensively, as a shorthand for the equivalent code:

if ((someObj === undefined) || (someObj === null))  {
  // do something
}

This is a consequence of the ECMAScript Language Specification § 11.9.3, The Abstract Equality Comparison Algorithm, which states, among other things, that

1.  If Type(x) is the same as Type(y), then  
    a.  If Type(x) is Undefined, return true.  
    b.  If Type(x) is Null, return true.

and

2.  If x is null and y is undefined, return true.
3.  If x is undefined and y is null, return true.

This particular technique is common enough that JSHint has a flag specifically designed for it.

share|improve this answer
1  
No fair answering your own question I wanted to answer this :) == null or undefined is the only place where I don't use === or !== –  pllee 11 hours ago
2  
To be fair jQuery is hardly a model codebase. Having read the jQuery source several times it's one of my least favorite codebases with a lot of nested ternaries, unclear bits, nesting and things I would otherwise avoid in real code. Don't take my word for it though - read it github.com/jquery/jquery/tree/master/src and then compare it with Zepto which is a jQuery clone: github.com/madrobby/zepto/tree/master/src –  Benjamin Gruenbaum 2 hours ago
    
Also note that Zepto seems to default to == and only uses === in cases where it's needed: github.com/madrobby/zepto/blob/master/src/event.js –  Hey 2 hours ago
    
@Hey to be fair Zepto is hardly a model codebase either - it's infamous for using __proto__ and in turn forcing it almost single handedly into the language specification to avoid breaking mobile websites. –  Benjamin Gruenbaum 50 mins ago

I'm going to make an argument for ==

Douglas Crockford which you cited is known for his many and often very useful opinions. While I'm with Crockford in this particular case it's worth mentioning it is not the only opinion. There are others like language creator Brendan Eich who don't see the big problem with ==. The argument goes a little like the following:

JavaScript is a behaviorally* typed language. Things are treated based on what they can do and not their actual type. This is why you can call an array's .map method on a NodeList or on a jQuery selection set. It's also why you can do 3 - "5" and get something meaningful back - because "5" can act like a number.

When you perform a == equality you are comparing the contents of a variable rather than its type. Here are some cases where this is useful:

  • Reading a number from the user - read the .value of an input element in the DOM? No problem! You don't have to start casting it or worrying about its type - you can == it right away to numbers and get something meaningful back.
  • Need to check for the "existence" of a declared variable? - you can == null it since behaviorally null represents there is nothing there and undefined doesn't have anything there either.
  • Need to check if you got meaningful input from a user? - check if the input is false with the == argument, it will treat cases the user has entered nothing or just white-space for you which is probably what you need.

Let's look at Crockford's examples and explain them behaviorally:

'' == '0'           // got input from user vs. didn't get input - so false
0 == ''             // number representing empty and string representing empty - so true
0 == '0'            // these both behave as the number 0 when added to numbers - so true    
false == 'false'    // false vs got input from user which is truthy - so false
false == '0'        // both can substitute for 0 as numbers - so again true

false == undefined  // having nothing is not the same as having a false value - so false
false == null       // having empty is not the same as having a false value - so false
null == undefined   // both don't represent a value - so true

' \t\r\n ' == 0     // didn't get meaningful input from user vs falsey number - true 

Basically, == is designed to work based on how primitives behave in JavaScript not based on what they are. While I don't personally agree with this point of view there is definitely merit in doing it - especially if you take this paradigm of treating types based on behavior language-wide.

* some might prefer the name structural typing which is more common but there is a difference - not really interested in discussing the difference here.

share|improve this answer
3  
This is a great answer, and I use all three of your 'for ==' use cases. #1 & #3 are especially useful. –  Chris Cirefice 2 hours ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.