Is the third = necessary when comparing object types? [closed]

问题

Give me one good reason why I shouldn't stop using the third equals.

typeof x === "object"
typeof x == "object" // does the same thing 100% of the time and uses one less character

回答1:

1 (very) good reason: consistency.

In general you should be as specific as possible. If you are following the general rule that you should be as specific as possible, you should keep it as === for consistency. Plus, assuming you follow the general rule, if you make an exception, then more exceptions will follow, and soon you won't have a general rule.

I'd take consistency and specificity over the hassle of having to type 1 character 100% of the time.

回答2:

In this specific situation, the only advantage of === is that it's slightly faster.

For profiling results, see: http://jsperf.com/equal-performance (specifically, "string + double equals" and "string + tripple equals").

回答3:

You're not comparing object types. You compare strings: the literal one ('object') and that returned by typeof operator.

Because you always will compare strings in this statement, I suppose using == or === will make no difference here.

回答4:

Ok, by now most people have told you (rightfully so) that using three = is best practice. However, your example brings up one of the possible pitfalls when using type of value-of comparisons. Take this for example:

var date1 = new Date();
var date2 = new Date(date1.valueOf());

This means dat both date1 and date2 are of the same type (objects, the same object even: Date) and have exactly the same value. So logically:

console.log(date1 === date2);//logs FALSE

Why? Because JS object variables are references. What the above statement is actually doing is checking if two locations in memory (both are new instances) are the same. Not their contents is checked, but their mem address.
Logic therefore dictates that:

var date1 = new Date();
var date2 = date1;
console.log(date1 === date2);//True

Note: JS always copies the values of its variables, but in case of objects, those variables are references, so JS copies the mem address that is stored in date1 to date2.

Fair enough, the checking of two separate instances is an issue that occurs with double equal signs, too. Regardless of type, or value even: two mem addresses are never the same.

A simple fix many people used to apply, was to overwrite the JS object prototype's valueOf method. This still works, but causes problems with type and value checking (the object type is still playing part, then):

function SomeConstructor()
{
    this.foo = 'foobar';
    this.bar = function()
    {
        console.log('I am a messy constructor!');
        return this.foo;
    };
}
var inst = new SomeConstructor();
inst.valueOf = function()
{
    return 1;
}

console.log(inst == 1);//logs true
console.log(inst === 1);//logs FALSE

There are many ways to get around this, I've seen people JSON.stringify-ing two objects, and parsing them afterwards, people using for...in to check each property,... While all that needs to be done is storing the valueOf() return value in an extra variable. Job Done(?) What people actually need to do is write better code, but I'm tired and drifting WAY off topic where.... back to the question at hand:

What then, might one ask, is the reason to choose for the extra = sign. Well, I see consistency is mentioned above, and marginal speed gain.
But just as no-one seems to have mentioned this pitfall, there is nobody mentioning stability.

By that I mean that, when you're writing code, especially in a soft typed language, that you find yourself writing functions or methods that assume a certain number of arguments of a certain type.
The next step, generally while debugging, is that your functions start with lines like argument1 = parseInt(argument1); and argument1 = argument1 || 0; code like this can never be avoided all together, but should be kept to a minimum.

Speaking for myself, I tend to check what types of arguments are expected when calling a function, if I see that the function does type and value checking. If it doesn't I assume the function will parse whatever data it needs from whatever arguments I choose to pass to it.
Basically: the stricter your code looks the stricter it is likely to be used.

回答5:

Third equals compare even data types.

JavaScript typeof returns strings, only if tested variable is null doesn't return "null", but null.

If you are comparing typeof x with string, second equals return always the same such as third.

回答6:

== - means check values of vars but dont check their types (e.g. "2" == 2 => return true).

=== - means check values and their types (e.g. "2" === 2 => return false, because the left argument is a string and second is a number, so vars doesnt the same)

EDIT: === in general the same as var1 == var2 && var1.contructor == var2.contructor.

来源：https://stackoverflow.com/questions/11403088/is-the-third-necessary-when-comparing-object-types

标签

javascript