== и! = Стало плохой практикой?

Question

== и! = Стало плохой практикой?

1

Начиная с нескольких месяцев, моя IDE (WebStorm) выделяет JavaScript регулярных операторов равенства со следующим предупреждением:

Comparioson a == b may cause unexpected type coercion.
This inspection reports usages of JavaScript quality operators which may cause unexpected
type coercions. It is considered a good practice to use the type-safe equality operators
=== and !== instead of their regular counterparts == and !=.

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

if(parseInt(val) == val) // val can be safely converted to int

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

if(parseInt(val).toString() === val) // be happy webstorm

Это действительно путь. или я должен игнорировать/отключать эти предупреждения?

RienNeVaPlu͢s 30 июнь 2017, в 01:12

Источник

1

== подходит только для if(x==null) так как он тоже попадает в undefined
dandavis 29 июнь 2017, в 22:57
1

т.е. не "хорошо" на самом деле
Lightness Races in Orbit 29 июнь 2017, в 22:59
0

Если, например, val имеет начальные или конечные пробелы или нули, ваше « решение » не будет работать.
PM 77-1 29 июнь 2017, в 22:59
0

@BoundaryImposition: как это не хорошо? Я никогда не хотел разделить волосы между нулем / неопределенным; оба означают "Нет". Зачем печатать больше, чем нужно, чтобы быть разборчивым; пусть компилятор справится с работой.
dandavis 29 июнь 2017, в 23:00
0

Потому что явное лучше, чем неявное, @dandavis.
Alexander Huszagh 29 июнь 2017, в 23:06
0

@AlexanderHuszagh: обычно, но два пустых значения JS - ошибка. Когда нужно различать?
dandavis 29 июнь 2017, в 23:08
1

@dandavis В чем разница между нулевым и неопределенным в JavaScript?
4castle 29 июнь 2017, в 23:11
0

@ 4castle: это не отвечает на мой вопрос. Я просто не верю, что у кого-то когда-либо была реальная необходимость использовать if(x===undefined||x===null) вместо if(x==null) , поскольку это всегда делает одно и то же ...
dandavis 29 июнь 2017, в 23:15
1

Бесполезно отмечать этот вопрос как дубликат вопроса, который был закрыт из-за неконструктивности. По сути, это говорит о том, что этот вопрос не является конструктивным.
RobG 29 июнь 2017, в 23:19
0

@dandavis Все плохие практики иногда полезны. Это не значит, что вы должны их использовать. Учитывая то, как большинство людей считают == плохой практикой, if (x == null) можно интерпретировать как опечатку для if (x === null) .
4castle 29 июнь 2017, в 23:23
0

@RobG: Я признаю, что это было немного глупо, но это простой способ указать на лучший из существующих источников "для получения дополнительной информации ...". Честно говоря, мое терпение к SO в настоящее время настолько низко, что мне все равно :)
Lightness Races in Orbit 30 июнь 2017, в 09:41
0

@RobG: Не совсем - «дубликат» на самом деле не означает «дубликат» и не имеет в течение некоторого времени; это означает, что «об этом уже спрашивали, если ваш ответ там ». Кроме того, я не считаю этот другой вопрос «неконструктивным»; к счастью, вы, ребята, уже открыли его сейчас :)
Lightness Races in Orbit 30 июнь 2017, в 09:44

Показать ещё 10 комментариев

Теги:

javascript

type-conversion

operators

warnings

equality

2 ответа

3

Да, это была лучшая практика в течение почти двух десятилетий.

Предупреждение довольно ясно (даже объясняя, почему оно на месте), и вы найдете тот же совет в своих JavaScript-книгах, а также широко в Интернете.

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

Вы можете найти дополнительную информацию о том, когда выбрать == и когда выбрать === здесь:

Когда можно использовать == в JavaScript?

Lightness Races in Orbit 29 июнь 2017, в 20:23

0

Вы подразумеваете, что неявное приведение типов - это плохо. Если ваше приложение достаточно неоднозначно, и вы не уверены, какие типы / значения вы собираетесь сравнивать, я думаю, у вашего кода есть большие проблемы. == эквивалентно === когда значения одного типа.
mhodges 29 июнь 2017, в 23:03
0

@mhodges А как насчет того, чтобы люди, злоупотребляющие вашей библиотекой, или новые разработчики, приходящие на проект, передавали неверные значения и получали странные результаты? Использование === помогает всем в долгосрочной перспективе и стоит дополнительного нажатия клавиши.
Clint 29 июнь 2017, в 23:17
2

Термин «лучшая практика» является довольно бессмысленным, если он не подкреплен критериями для определения «лучших».
RobG 29 июнь 2017, в 23:21
0

@ 4castle: Возможно (хотя см. Мой комментарий под вопросом). Я теперь превратил dupevote в перекрестную ссылку
Lightness Races in Orbit 30 июнь 2017, в 09:41
0

@mhodges: Нет, как говорится в тексте предупреждения, проблема заключается в неожиданных приведениях типов. Если вы знаете, что хотите принуждения, тогда отлично.
Lightness Races in Orbit 30 июнь 2017, в 09:42
0

@BoundaryImposition Точно. Если вы хотите приведение типов (что во многих случаях полезно), то == выгоднее, чем === . Это означает, что === - это не "лучшая практика", а правильный выбор во многих ситуациях. Тем не менее, == также является правильным выбором во многих ситуациях. Укажи на случай - знай язык и используй синтаксис соответствующим образом.
mhodges 30 июнь 2017, в 15:06
0

@mhodges: "лучшая практика по умолчанию", возможно
Lightness Races in Orbit 30 июнь 2017, в 15:14
1

@BoundaryImposition Во всей реальности существует лишь небольшое количество значений, которые дают неожиданные результаты при использовании неявного приведения типов в выражениях сравнения. Если вы можете знать это и избегать их, == абсолютно безопасно. Это похоже на дебаты var vs let/const . let / const не является новой переменной, () => не является новой function и === не является "новой" == . Каждый из них служит различным, но очень законным целям.
mhodges 30 июнь 2017, в 15:53
0

@Mhodges: Действительно.
Lightness Races in Orbit 30 июнь 2017, в 15:55

Показать ещё 7 комментариев

Ещё вопросы

== подходит только для if(x==null) так как он тоже попадает в undefined
Если, например, val имеет начальные или конечные пробелы или нули, ваше « решение » не будет работать.
@BoundaryImposition: как это не хорошо? Я никогда не хотел разделить волосы между нулем / неопределенным; оба означают "Нет". Зачем печатать больше, чем нужно, чтобы быть разборчивым; пусть компилятор справится с работой.
Потому что явное лучше, чем неявное, @dandavis.
@AlexanderHuszagh: обычно, но два пустых значения JS - ошибка. Когда нужно различать?
@dandavis В чем разница между нулевым и неопределенным в JavaScript?
@ 4castle: это не отвечает на мой вопрос. Я просто не верю, что у кого-то когда-либо была реальная необходимость использовать if(x===undefined||x===null) вместо if(x==null) , поскольку это всегда делает одно и то же ...
Бесполезно отмечать этот вопрос как дубликат вопроса, который был закрыт из-за неконструктивности. По сути, это говорит о том, что этот вопрос не является конструктивным.
@dandavis Все плохие практики иногда полезны. Это не значит, что вы должны их использовать. Учитывая то, как большинство людей считают == плохой практикой, if (x == null) можно интерпретировать как опечатку для if (x === null) .
@RobG: Я признаю, что это было немного глупо, но это простой способ указать на лучший из существующих источников "для получения дополнительной информации ...". Честно говоря, мое терпение к SO в настоящее время настолько низко, что мне все равно :)
@RobG: Не совсем - «дубликат» на самом деле не означает «дубликат» и не имеет в течение некоторого времени; это означает, что «об этом уже спрашивали, если ваш ответ там ». Кроме того, я не считаю этот другой вопрос «неконструктивным»; к счастью, вы, ребята, уже открыли его сейчас :)
Вы подразумеваете, что неявное приведение типов - это плохо. Если ваше приложение достаточно неоднозначно, и вы не уверены, какие типы / значения вы собираетесь сравнивать, я думаю, у вашего кода есть большие проблемы. == эквивалентно === когда значения одного типа.
@mhodges А как насчет того, чтобы люди, злоупотребляющие вашей библиотекой, или новые разработчики, приходящие на проект, передавали неверные значения и получали странные результаты? Использование === помогает всем в долгосрочной перспективе и стоит дополнительного нажатия клавиши.
Термин «лучшая практика» является довольно бессмысленным, если он не подкреплен критериями для определения «лучших».
@ 4castle: Возможно (хотя см. Мой комментарий под вопросом). Я теперь превратил dupevote в перекрестную ссылку
@mhodges: Нет, как говорится в тексте предупреждения, проблема заключается в неожиданных приведениях типов. Если вы знаете, что хотите принуждения, тогда отлично.
@BoundaryImposition Точно. Если вы хотите приведение типов (что во многих случаях полезно), то == выгоднее, чем === . Это означает, что === - это не "лучшая практика", а правильный выбор во многих ситуациях. Тем не менее, == также является правильным выбором во многих ситуациях. Укажи на случай - знай язык и используй синтаксис соответствующим образом.
@mhodges: "лучшая практика по умолчанию", возможно
@BoundaryImposition Во всей реальности существует лишь небольшое количество значений, которые дают неожиданные результаты при использовании неявного приведения типов в выражениях сравнения. Если вы можете знать это и избегать их, == абсолютно безопасно. Это похоже на дебаты var vs let/const . let / const не является новой переменной, () => не является новой function и === не является "новой" == . Каждый из них служит различным, но очень законным целям.

Alexander Huszagh · Accepted Answer · 2017-06-29T21-18-00.000Z

2

Лучший ответ

Я бы сказал, что любая форма тикового принуждения, если она неожиданна для типов, которые не могут быть известны во время выполнения (например, любой динамический язык), является плохой практикой.

Например, они оба правдивы:

 "0" == false
 "0"

Хотя это ложно:

 false

Alexander Huszagh 29 июнь 2017, в 21:18

1

Если вы пытаетесь сравнить два значения, и у вас нет абсолютно никакого представления о каком-либо из этих типов, как вы узнаете, достигнет ли === предсказуемого результата больше, чем == ? Если вы находитесь в полной темноте, вам все равно придется выполнить некоторую проверку типов перед вычислением равенства.
RobG 29 июнь 2017, в 23:31
1

@robg Потому что явное всегда лучше, чем неявное. Если вы не знаете, что он мог передать, как, например, в сериализованном виде, вы можете явно проверить несколько случаев и выдать ошибку или иметь обработчик по умолчанию для остальных случаев. Это также спасает вас от случаев, когда вы изначально проектировали функцию для одного использования, а затем расширяете ее для нового использования и получаете неожиданные результаты из-за неявного поведения.
Alexander Huszagh 29 июнь 2017, в 23:38
0

Эти комментарии относятся к обоим случаям. Моя проблема заключается в обобщении === как "наилучшей практики" без учета того, что на самом деле является "наилучшей практикой". Это часто приводит к разным результатам в разных случаях, и приведение типов выполняется все время, чтобы получить рабочий день ISO, я использую date.getDay() || 7 Поэтому может быть целесообразно использовать === в некоторых случаях и == в других. Повторное использование кода может привести ко многим проблемам, а не только к тем, которые возникают в результате абстрактного или строгого сравнения. ;-)
RobG 30 июнь 2017, в 01:00

Показать ещё 1 комментарий