2

For example if I do if ("11" == 11) this will give true because the string will be converted to number so it will be like testing if (11 == 11) and that is true

It I instead use if ("11" === 11) this will give false because no conversion is made.

I can understand this but now to my question.

So because of my test previously it seems like we should always use === to prevent any automatic conversion when testing for equality.

So what guideline exist when to use == for equality and when to use === for equality.

Ian
  • 50,146
  • 13
  • 101
  • 111
user2658578
  • 365
  • 2
  • 5
  • I always use `==` except when *I know I want* strict equality. – user2246674 Sep 11 '13 at 20:31
  • "The identity (===) operator behaves identically to the equality (==) operator except no type conversion is done, and the types must be the same to be considered equal." http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons – Tore Sep 11 '13 at 20:31
  • 4
    @user2246674 Maybe it's just me, but I work the opposite way. Why would you want possibly inconsistent results? – Ian Sep 11 '13 at 20:32
  • @Ian Why are they inconsistent? The operations are perfectly defined in the standard. Each external method should be accompanied by documentation that explains the behavior - and thus I write my methods (and contracts) to work with `==` except when I want otherwise. – user2246674 Sep 11 '13 at 20:32
  • @user2246674: Check out [some examples](http://wtfjs.com/page/2). – Jezen Thomas Sep 11 '13 at 20:33
  • @JezenThomas Entirely explained with the standard. Also the use of `'true' == aThruthyValue` represents a *coding error*. – user2246674 Sep 11 '13 at 20:34
  • @Ian Well, `==` is consistent. The rules for [abstract equality](http://es5.github.io/#x11.9.3) are well defined. How familiar someone is with them is a different matter. – Jonathan Lonowski Sep 11 '13 at 20:34
  • @user2246674: Settle down... my goodness. – user2736012 Sep 11 '13 at 20:34
  • @JonathanLonowski As well has how familiar one is with variable scoping .. – user2246674 Sep 11 '13 at 20:35
  • @JonathanLonowski I didn't mean inconsistent results as in the spec doesn't define them. I meant more what your second sentence said - familiarity and use is the key – Ian Sep 11 '13 at 20:35
  • I favor strict equality unless I have a reason. But I also have some quirks -- one example of a situation where I never use === is `typeof someVar == 'undefined'` -- if typeof is returning something not stringy that still matches "undefined", I'll take it! – Chris Baker Sep 11 '13 at 20:43
  • @user2246674 I think what I more meant to say was: I'd rather have consistent results because I'm enforcing what I expect. If someone passes a string that's truthy, that's not the same as `true` to me. Of course, I'm sure this is on a per-situation basis for some people. And documentation/contracts mean nothing, people can do what they want. I'd rather let it fail consistently because the developer passed the wrong stuff, than silently working. So I guess it really depends on your opinion of the use. And I should've clarified better what I meant by "consistent" – Ian Sep 11 '13 at 20:43

0 Answers0