Третье = необходимо при сравнении типов объектов?

Ответ 1

1 (очень) веская причина: консистенция.

В общем вы должны быть как можно более конкретными. Если вы выполняете общее правило, что вы должны быть как можно более конкретными, вы должны сохранить его как === для согласованности. Плюс, предполагая, что вы следуете общему правилу, если вы сделаете исключение, то последуют больше исключений, и вскоре у вас не будет общего правила.

Я бы принял согласованность и специфичность в связи с необходимостью набирать 1 символ 100% времени.

Ответ 2

В этой конкретной ситуации единственным преимуществом === является то, что он немного быстрее.

Результаты профилирования см. в разделе http://jsperf.com/equal-performance (в частности, "строка + двойные равны" и "строка + триплекс равно" ).

Ответ 3

Вы не сравниваете типы объектов. Вы сравниваете строки: буквальный ('object') и возвращаемый оператором typeof.

Поскольку вы всегда будете сравнивать строки в этом выражении, я полагаю, что использование == или === здесь не имеет значения.

Ответ 4

Хорошо, к настоящему времени большинство людей сказали вам (по праву), что использование трех = - лучшая практика. Тем не менее, ваш пример вызывает одну из возможных ошибок при использовании сравнений type of value-of. Возьмите это, например:

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

Это означает, что оба date1 и date2 имеют один и тот же тип (объекты, один и тот же объект: Date) и имеют точно такое же значение. Логично:

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

Почему? Потому что переменные объекта JS являются ссылками. То, что приведенный выше оператор фактически выполняет, - это проверка того, являются ли два места в памяти (оба являются новыми экземплярами) одинаковыми. Не проверяется их содержимое, но их адрес mem.
Логика поэтому диктует, что:

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

Примечание. JS всегда копирует значения своих переменных, но в случае объектов эти переменные являются ссылками, поэтому JS копирует адрес mem, хранящийся в date1, на date2.

Достаточно честно, проверка двух отдельных экземпляров - проблема, которая встречается с двойными равными знаками. Независимо от типа или значения: два mem-адреса никогда не совпадают.

Простое исправление, применяемое многими людьми, заключалось в том, чтобы перезаписать метод прототипа объекта JS valueOf. Это все еще работает, но вызывает проблемы с проверкой типа и значения (тип объекта все еще играет роль, затем):

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

Есть много способов обойти это, я видел людей JSON.stringify -в двух объектах и ​​потом их анализируя, люди, использующие for...in, чтобы проверить каждое свойство... Хотя все это нужно сделать сохраняет возвращаемое значение valueOf() в дополнительной переменной. Job Done (?) То, что действительно нужно делать людям, - это писать лучший код, но я устал и дрейфую. Откажитесь от темы, где... вернитесь к вопросу:

То, что можно спросить, является причиной выбора дополнительного знака =. Ну, я вижу, что консистенция упомянута выше, и предельная скорость.
Но так же, как никто, кажется, не упомянул об этой ловушке, никто не упоминает о стабильности.

Под этим я подразумеваю, что, когда вы пишете код, особенно на мягком типизированном языке, вы обнаруживаете, что пишете функции или методы, которые принимают определенное количество аргументов определенного типа.
Следующий шаг, как правило, во время отладки, заключается в том, что ваши функции начинаются с таких строк, как argument1 = parseInt(argument1); и argument1 = argument1 || 0; код, подобный этому, никогда нельзя обойти все вместе, но его следует свести к минимуму.

Говоря о себе, я стараюсь проверить, какие типы аргументов ожидаются при вызове функции, если я вижу, что функция выполняет тип и проверку значений. Если это не так, я предполагаю, что функция будет анализировать любые данные, которые ему нужны, из любых аргументов, которые я выбираю для передачи.
В принципе: более строгий код выглядит более строгим, и он, вероятно, будет использоваться.

Ответ 5

== - означает проверочные значения vars, но не проверяет их типы (например, "2" == 2 = > return true).

=== - означает контрольные значения и их типы (например, "2" === 2 = > return false, потому что левый аргумент является строкой, а второй - числом, поэтому vars не то же самое)

EDIT: === в целом то же самое, что и var1 == var2 && var1.contructor == var2.contructor.

Ответ 6

Третий означает сравнение даже типов данных.

JavaScript typeof возвращает строки, только если проверенная переменная равна null, не возвращает "null", но null.

Если вы сравниваете typeof x с строкой, второй равно возврату всегда такой же, как третий.