Блог

Когда лучше использовать == в JavaScript?

Редакция Lodoss Team
0

Если коротко: никогда. В этой статье рассмотрим 5 примеров, когда логично использовать ==, и объясним, почему этого все же не стоит делать.

В JavaScript есть два оператора для сравнения двух значений:

1.Оператор строгого равенства === считает равными только те значения, которые имеют одинаковый тип.
2.Обычный (или нестрогий) оператор равенства == пытается преобразовать значения разных типов перед сравнением

Совет начинающим JavaScript-разработчикам - полностью забыть о == и всегда использовать === . Как выяснилось, это правило универсально. Есть несколько ситуаций, которые выглядят как исключения из этого правила, но на самом деле это не так. Принцип, которым мы руководствуемся:

Понятный код лучше короткого.

Запомните: ваш код будет написан 1 раз, а прочитан - много раз, поэтому постарайтесь сделать его максимально понятным.

Случай 1: Вы знаете, что с чем сравниваете

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

Однако, есть две причины этого не делать:

1.Постоянство: здесь вы не получаете никаких преимуществ от использования == здесь, так почему же отступать от простого правила избегать его?
2.Простота и производительность: в общем случае === является более простой операцией, поскольку она не преобразует свои операнды. Производительность в разных движках JavaScript отличается, но в большинстве браузеров === быстрее, чем == .

Случай 2: сравнение с null и undefined

С == , undefined и null находятся в одном классе эквивалентности —  они равны себе и друг другу, но ничему другому (включая значения, которые в JavaScript считаются ложными):

Таким образом, следующий оператор if проверяет наличие undefined и null.

Тем не менее, незначительное сокращение количества кода оборачивается тем, что по такому коду сложно понять ваши намерения: если вам нужна и проверка на undefined, то лучше описать это явно. В противном случае, если новичок прочитает ваш код, он может подумать, что вы проверяете только на null. А опытный программист скорее всего решит, что вы допустили ошибку и собирались написать === .

И также можно встретить такую не очень безопасную запись:

Имейте в виду, что условие будет выполняться, если x имеет любое из следующих «ложных» значений:

Случай 3: сравнение строки и числа


Сценарий: вы работаете над кодом пользовательского интерфейса или кодом, который обрабатывает параметры на  сервере. Тогда вы, вероятно, получите закодированные числа в виде строк. Сравнить строку x с числом можно при помощи ==:

Но лучше явно указать для тех, кто будет читать ваш код, что если х не является числом, его следует сначала преобразовать в число:

Случай 4: сравнение объектов с примитивами

С помощью == вы можете сравнить примитив либо с примитивом, либо с объектом типа обертки:

Со строгим сравнением === так не получится:

Слева — объект, а справа — примитив. У них разный тип и, следовательно, они не являются строго равными. Опять же, лучше снова сделать упор на читабельность кода. Когда вы пишете следующее выражение:

Чего именно вы хотите достичь?
1.Вам нужно сравнить переменную со строкой или объектом строки? Это выглядит немного необычно, и если это действительно так, то лучше это указать в документации.
2.Вы хотите преобразовать x в строку? Тогда вы можете написать более явно.

3.Вы хотите извлечь значение объекта-обертки? Тогда лучше написать:

Случай 5: JavaScript гибкий — наш код тоже должен быть таким

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

В этом кроются несколько неприятных моментов:
1.Даже стандартные преобразования могут не всегда работать так, как надо. Примеры:

2.Нестрогое сравнение работает не так, как обычное преобразование:

3.Явное преобразование плюс строгое сравнение приводит к более наглядному коду. Сравните: гибкость с мягким сравнением.

4. Альтернатива: можно попробовать достичь гибкости и со строгим сравнением:

5.Кто сказал, что ваш код обязательно должен быть гибким? Можно утверждать, что гибкость JavaScript - это на самом деле баг, а не фича. Написание безопасного кода помогает быстрее выявить ошибки в будущем. Безопасная версия is123Explicit () выглядит следующим образом:

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

Заключение

Хороший программист придерживается простого правила: «не использовать ==», и это правило важно не только для новичков. Меньше магии в коде, и его будет намного легче понять.

When is it OK to use == in JavaScript?

Над статьей работали:
Марина Мошногорская
Татьяна Семченко

0