In a code review that I was doing to a coworker, I said that here:

if (someValue === 'final'){

There is no sense to use strict comparison because the only way to pass it as true is with other string value equals to final.

I think that it is enough:

if (someValue == 'final'){

His argument is that an object could have a toString method that returns that string but strictly it does not have the same datatype.

While that is true, as a computer(that are not intelligent as human), in the other hand, there is not sense, as at the end of the way the only way to pass this as true is with a string equals to final. This was his sample code:

Test = function(){}
Test.prototype.toString = function () { return 'final'; }
var disagreeDaniel = new Test();
document.getElementById('foo').innerHTML = (disagreeDaniel == 'final');

So my point here guys, is that I need you get better explanation to him why there is not sense of the strict comparison on a fixed strict like 'final' because there is no way to pass it as positive with a value different than 'final'.(his example at the end return the string)

For me strict comparison is useful for booleans, nulls, undefined, zero, where those could pass all as false in some cases. I want to hear your opinions.

====== Update ==========

It is easy to identify that people does not read. My question was the sense of use === to compare to 'final'. I got a lot of explanations of things nothing to do. For compare to null, false, zero etc, I said that I used === for THOSE cases but not for long strings. but people tried to explained me about null, false, zero, etc. The verdict until now is that there is not a SOLID argument(there are some good ones but not solid) that demonstrate why using === for compare to 'final' should be better than use ==(read again, is just this use case, I'm talking about one specific use case).

I also spoke with my coworker, I gave him the +1 to the code. I do not have problems with ===, my problem never had to use it, my point always was and is, and will be, what should be the sense, and looks like it would be a question with nevertheless answer.

ps. other thing that I learned time ago, is to never be aggressive with other opinions; "technical topics" for several programmers, are like religion for religious(and some guys here just remembered me it).

ps2. I marked as solved to be democratic, I do not want to demonstrate anything, just thought this site is for good discussions, and I got that. :D

  • 4
    Use === for consistency. You don't want to always have to think about edge cases. Consistency in code is super important, much more than the extra "=" Commented Aug 15, 2013 at 18:57
  • 5
    I'm afraid I didn't understand your objection to using triple equals. I've run your coworkers's code and it outputs true. That would indicate he is right and a malicious or careless type could pass the condition despite not being a string.
    – user7043
    Commented Aug 15, 2013 at 19:05
  • It is not objections, everything here is regarding the sense. There are not any use case where == should be a problem. (in this specific case 'final'). While also === is not an issue, I liked also to have common sense, is what differs us from a computer. Commented Aug 15, 2013 at 19:08
  • 2
    @DanielAranda While I agree with Esailija's standpoint as I've stated in my answer before, I find the notion of someone overriding toString of an object for the purpose of it being equal final absurd. We should not have to code to cater this sort of behavior. The fact == can be 'tricked' to accept an object as equal to the string final is an extremely poor argument against it IMHO where cognitive load and consistency in code are both much much better arguments. Commented Aug 16, 2013 at 12:33
  • @BenjaminGruenbaum now you are following my point. :) Commented Aug 16, 2013 at 15:09

2 Answers 2


Yes, for example typeof x == "string" is functionally exactly the same as typeof x === "string".

However, x == " ", is not even remotely the same as x === " " since a string that is full of whitespace coerces towards 0 and 0 == " " //true or false == " " //true .

=== is written because the extra cognitive load required to judge each scenario individually for possible one character savings is just not worth it. I bet you that you or most programmers did not even know about the whitespace strings. Your brain needs to confirm that == "final" is not in any corner case, and only then you can proceed writing it.

You can wake me up the middle of the night and I will recite all the == rules and corner cases by heart, but that doesn't mean I will want to go through to them every time an equality comparison is needed.

A notable exception is == null which should be memorized as "undefined or null" and is even specially supported by jshint which otherwise enforces ===.

And wait, there is more. From spec

ECMAScript implementations must recognise all of the white space characters defined in Unicode 3.0. Later editions of the Unicode Standard may define other white space characters. ECMAScript implementations may recognise white space characters from later editions of the Unicode Standard

That implies the operation == is implementation defined for comparisons of string and boolean/object/number

For example:

function equals( x ) {
    return x == "\ufeff\ufeff";

Gives true on Firefox but false on Chrome.

  • +1, When is == ok in code? Are there times where it's useful? Commented Aug 15, 2013 at 19:02
  • 3
    "extra cognitive load required to judge each scenario individually for possible one character savings is just not worth it", that is a valid argument. Commented Aug 15, 2013 at 19:15
  • I'm more fan of judge each scenario individually, that could mark the difference that I wanted to hear. Thank You! Commented Aug 15, 2013 at 19:16
  • 1
    @BenjaminGruenbaum: Yes. == is useful wherever type coercion is specifically desired. Otherwise, it should not be used in preference of explicit conversions.
    – greyfade
    Commented Aug 15, 2013 at 21:44

The question I would ask your coworker is why someone would go through all the trouble of creating an object with an appropriate toString method, then not want it to compare equal to 'final'? In other words, why would not being the same type be a problem if the values are semantically equivalent? Certainly no one is going to write code like his counter-example by accident.

In my opinion, using strict comparison when it isn't needed violates the open/closed principle. It shuts down potential avenues of extension. Not using a feature of a language for the sake of "consistency" is ridiculous. You don't write i += 1 instead of i++ so you can be consistent with i += 2. By all means, be consistent where the situations are the same, but don't be a slave to superficial consistency when the situations differ.

Most people think of the OCP in terms of classes, but it also applies to functions. In general, it means to minimize the amount of code that will need to change when you add functionality to your program. In other words, prefer adding code to changing code.

99% of the time, you should be comparing two values of the same type, and those times where comparing different types is required should be blindingly obvious and intentional. If you have no idea whether someValue is a string or not, you have bigger fish to fry.

  • I love the answers that I'm getting. Definitely I think the same, that there is not reason to use strict comparison when it isn't needed. Thank You! Commented Aug 16, 2013 at 4:50
  • 2
    The imagined connection to OCP here is just ridiculous. Are these really becoming such buzz words?
    – Esailija
    Commented Aug 16, 2013 at 11:23
  • 1
    @Benjamin, OCP is not just for classes. It applies at the function level too. If you unnecessarily require code at any level to be changed in order to be extended, that's an OCP violation. Commented Aug 16, 2013 at 14:13
  • 1
    @BenjaminGruenbaum that is a valid argument "is hard to remember the ECMA rules". That is what I wanted to hear. I was not looking for consistency, as that should be a question for standards. In my question I was being asking for something specific. Commented Aug 16, 2013 at 15:07
  • 1
    @KarlBielefeldt Let's break it up a little - I want people who use my modules in code (be they classes, functions, or even just blocks) and want to add functionality to them to add that functionality on top of the existing API while keeping it consistent instead of making any modifications that make the API. Writing code that's easy to extend has nothing to do with a == check, if anything - if I have a supertype and a subtype that overrides toStrings to hack around the language spec I can easily break the LSP for instance. I'd love to hear an actual use case for using == for OCP. Commented Aug 16, 2013 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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