3

I know that there are many quirks with the equality operator (==). For example, following are all true...

null == undefined
1 == '1'
true == 1
false == ''

In all the above cases, using identity operator (===) would have returned the (strictly) correct answer.

But, when I just want to compare simpler things that do not suffer from quirks, why shouldn't I use the equality operator. For example...

typeof x == 'number'
str == 'something'

So, my question is; why does the equality operator have such a derogatory status, when in fact it's useful in some situations.

treecoder
  • 43,129
  • 22
  • 67
  • 91
  • 1
    I haven't heard that it shouldn't be used. I use it often when I don't care for comparing the exact same type (or if multiple types are allowed) – musefan Oct 15 '12 at 11:08
  • 4
    It isn't _always_ bad practice, so long as you understand the difference between `==` and `===` and know when to use each. – Keith Oct 15 '12 at 11:09
  • See here: http://stackoverflow.com/questions/359494/javascript-vs-does-it-matter-which-equal-operator-i-use – Jordan Oct 15 '12 at 11:09
  • Reading [this](https://github.com/rwldrn/idiomatic.js) document, it seems that it is indeed considered a bad practice. – treecoder Oct 15 '12 at 11:11
  • 2
    @good_computer: if only that document had some sort of disclaimer at the top about being opinions about style and that you should feel free to use your own style... oh wait, it does. (and, in fact, also says "Prefer `===` over `==` (unless the case requires loose type evaluation)" – Wooble Oct 15 '12 at 11:13
  • @Wooble Oh, I didn't read that. Thanks. I think that sums up this question and the issue. – treecoder Oct 15 '12 at 11:16
  • 1
    @good_computer: So... you read one article and assumed that was the standard for everyones opinion? – musefan Oct 15 '12 at 11:18
  • 1
    @musefan No, actually I have seen it several times people advocating `===` over `==` in each case. – treecoder Oct 15 '12 at 11:20

5 Answers5

6

It is considered bad because of something called type coercion.

It means that "" == false is true in JavaScript, but "" === false is not.

That might be what you want, but might not be.

Saying this is ALWAYS bad practice is too much of a sweeping statement. It is bad if you don't know what it does and means.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    Yes I know that. But `typeof x == 'something'` does NOT suffer from type coercion. Why can't I use it there? – treecoder Oct 15 '12 at 11:09
  • 2
    I disagree that this makes it bad. As long as you are aware of the difference between the two, you can use `==` quite validly. For example, checking for a valid form field, it is useful to be able to do something like `if(!fieldValue)` – musefan Oct 15 '12 at 11:09
  • @good_computer - If it doesn't, then go ahead and use it. – Oded Oct 15 '12 at 11:10
3

There is absolutely nothing wrong with using == when the operands are guaranteed to be of the same type. When the operands are of the same type, it is specified to perform exactly the same steps as ===. A good example is when using typeof.

The reason for == being frowned upon in such circumstances is purely stylistic. The argument is that code is easier to read if === is used consistently throughout without having to consider the implications of seeing a use of ==. A lot of this originates with Douglas Crockford and is perpetuated by his JSLint tool.

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • 2
    There's nothing wrong with using it when operands aren't of the same type either, provided the possible values and their Types are understood and appropriate. – RobG Oct 15 '12 at 12:07
  • Its good to avoid type coercion if possible. – Anthony O Feb 02 '22 at 18:19
  • 1
    @AnthonyO: In general, I agree. My point in this answer is that there is no type coercion if you know the types of the operands and that they are the same. Tbh, years of IDEs flagging every instance of `==` as an error has worn me down and I can no longer be bothered to fight this one. – Tim Down Feb 03 '22 at 11:35
0

Only for one exception, when the return type is fixed.

When compare with same types, type convention won't happen by using ==.

For example, typeof always return string,

so you could use typeof func == 'function' instead of typeof func === 'function' with no harm. (Which saves your one byte.)

xdazz
  • 158,678
  • 38
  • 247
  • 274
  • I could also do `fieldValue == 1` with no harm too, if I wanted to check a form field for the number 1 – musefan Oct 15 '12 at 11:13
  • @musefan Nope, you should not use for variables, how could you know the variable if also number type? – xdazz Oct 15 '12 at 11:15
  • point is, in this case I don't have to know. Besides I know in my example it will be a string type anyway – musefan Oct 15 '12 at 11:16
  • @musefan so try this, `'1e0' == 1` – xdazz Oct 15 '12 at 11:17
  • 1
    and the result is true! perhaps my example wasn't the best, I cannot even think of a situation where I would want to check for 1 (and actually only want "1") anyway. My point was that as long as you know what `==` actually does then it is fine to use – musefan Oct 15 '12 at 11:23
0

If you use both then sooner or later you will make a mistake and use == in a case where you shouldn't have. Not to mention the extra brain-cycles needed to decide if you should use === or == in each case. Sticking to === and forgetting == is less error prone and one less thing to keep in mind.

Supr
  • 18,572
  • 3
  • 31
  • 36
  • Sure, but then it's more processing on browser's part. It will have to do strict type checking every time, even when it's not needed. – treecoder Oct 15 '12 at 11:15
  • Is it? I don't know how browsers implement it, but I would expect a type check to be faster than coercion. Anyway, how much slower could it possibly be? For most use cases it is insignificant, especially compared to the downsides. – Supr Oct 15 '12 at 11:21
  • Yes I know it is insignificant, but still it feels useless to type check when it's not needed. – treecoder Oct 15 '12 at 11:22
  • 1
    @good_computer—for `==`, the browser must first check Types (as it does with `===`), then convert operands to the same Type before evaluating them. `===` skips the conversion step since if the Types are different, it's already returned `false`. But the performance difference is likely negligible. – RobG Oct 15 '12 at 12:14
0

I should also add that there can be situations where double equal signs is preferred, if you know what it does. F.ex if you need to invalidate "0" and 0 equally:

function validate(input) {
    return input == false;
}

validate(0); // false
validate("0") // false
David Hellsing
  • 106,495
  • 44
  • 176
  • 212