What should be the sense to use strict comparison to this specific string: 'final'

Question

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

Answer 1

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";
}
alert(equals(0));

Gives true on Firefox but false on Chrome.

Answer 2

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.