Почему это плохая идея разрешить их в JavaScript ==,! =, ++, -

Я проверял JSLint, и некоторые из правил вызвали мой интерес. Особенно это:

Запретить == и!=

Запретить ++ и -

Почему это плохая идея запретить их? Я понимаю первую часть, в основном она хочет, чтобы я сделал === вместо ==. Я не понимаю, почему. Я понимаю разницу между ними, я просто хочу знать, почему это плохая практика. Иногда я действительно хочу сделать ==, например, чтобы он оценивал значение true для undefined == null

Второй, ну я вообще не понимаю. Он хочет, чтобы я сделал myInt + = 1 вместо myInt ++?

Спасибо!

Ответы

Ответ 1

Douglas crockford (парень, который написал JSLint) объясняет себя в этом видео:

http://www.youtube.com/watch?v=hQVTIJBZook#t=14m45s

но в основном (как все остальные упоминали) это из-за типа coercian.

Стоит посмотреть, какое видео будет честным - очень интересно и полезно.

Ответ 2

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

Основная причина, по которой Crockford хочет избежать ==, заключается в том, что правила сравнения в зависимости от типов операндов могут сделать этот оператор нетранзитивным, например, если:

A == B AND
B == C

Не гарантирует, что:

A == C

Реальный пример:

'0' == 0; // true
 0 == '';   // true
'0' == ''; // false

Строгий оператор === не нужен, когда вы сравниваете значения одного и того же типа, например:

 if (typeof foo == "function") { }

Мы сравниваем результат оператора typeof, который всегда является строкой, с строковым литералом...

Другой пример, когда вы сравниваете что-то против null, == также сравнивается с undefined, например:

if (something == null) {}

VS

if (something === null || typeof something === "undefined") {}

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

Изучение того, как работает оператор ==, поможет вам мудро решить, что использовать.

Рекомендуемые статьи:

Ответ 3

У Дуга Крокфорда есть свои идеи о том, что "хорошо" и "плохо" в Javascript. Соответственно, JSLint реализует эти проверки, но делает их необязательными, если вы не полностью согласны с ним.

Запрет == помогает предотвратить ошибки, если вы действительно имели в виду ===. Конечно, это предполагает, что вы никогда не хотите использовать ==.

Запрет ++ и -- - это стиль, некоторые считают, что их труднее читать, чем += 1 и -= 1.

Ответ 4

Из инструкции:

Операторы == и!= перед применением сравнивают тип принуждения. Это плохо, потому что это приводит к тому, что '\ t\r\n' == 0 является истинным. Это может маскировать ошибки типа.

и

Известно, что операторы ++ (increment) и - (декременты) вносят свой вклад в плохой код, поощряя чрезмерную хитрость. Они уступают только ошибочной архитектуре, позволяя вирусам и другим угрозам безопасности. Существует опция plusplus, которая запрещает использование этих операторов.

Ответ 5

Операторы == и !=, если необходимо, неявные конвейеры операторов, а операторы === и !== этого не делают. Выражение 4 == '4', например, будет истинным, а выражение 4 === '4' будет ложным.

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

Операторы ++ и -- не вызывают никаких проблем, если они используются отдельно в инструкции, но они часто используются, чтобы сделать утверждение, которое делает несколько вещей не так очевидным образом, например

arr[++idx] = 42;

который был бы более ясным как:

idx += 1;
arr[idx] = 42;

Ответ 6

Поведение стандартных операторов равенства (== и! =) зависит от версии JavaScript. Так что одна причина не использовать их.

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

См. https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Operators/Comparison_Operators

Ответ 7

Я понимаю ==. (исключение undefined == null)

("0" == false) === true
("0" === false) === false

Я никогда не понимал вещи ++ и --. Мне не нравится делать i+=1 по всему моему коду (медленнее, чем ++i).