In a code review that I was doing to a coworker, I said that here: if (someValue
ID: 646963 • Letter: I
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.
Explanation / Answer
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 == "ufeffufeff";
}
alert(equals(0));
Gives true on Firefox but false on Chrome.