Недавно я запускал часть своего кода через JSLint, когда обнаружил эту ошибку. Мне кажется забавным в этой ошибке то, что она автоматически предполагает, что все == должно быть ===.
Это действительно имеет смысл? Я видел много примеров, в которых вы не хотели бы сравнивать типы, и меня беспокоит, что это действительно может вызвать проблемы.
Слово «Ожидается» подразумевает, что это нужно делать ВСЕГДА ... Это то, что для меня не имеет смысла.
javascript
jslint
Мегаполис
источник
источник
myVar == null
проверку, да, большие изменения. ; ^) Крокфорд утверждает, что это сделало смысл кода более точным, и с этим трудно спорить.Ответы:
ИМО, слепое использование
===
, не пытаясь понять, как работает преобразование типов , не имеет большого смысла.Основное опасение по поводу оператора Equals
==
состоит в том, что правила сравнения в зависимости от сравниваемых типов могут сделать оператор нетранзитивным, например, если:На самом деле не гарантирует, что:
Например:
'0' == 0; // true 0 == ''; // true '0' == ''; // false
Оператор Strict Equals на
===
самом деле не нужен, когда вы сравниваете значения одного и того же типа, самый распространенный пример:if (typeof foo == "function") { //.. }
Мы сравниваем результат
typeof
оператора, который всегда является строкой , со строковым литералом ...Или, например, когда вы знаете правила приведения типов, проверьте, есть ли что-то
null
илиundefined
что-то:if (foo == null) { // foo is null or undefined } // Vs. the following non-sense version: if (foo === null || typeof foo === "undefined") { // foo is null or undefined }
источник
===
оператора - ясность кода. Нет разумной ситуации для использования,==
поскольку она никогда не будет такой ясной и понятной, как оператор идентификации. Дело не в том, понимаете ли вы операторы или нет, а в том, чтобы использовать тот, который делает ваш код более читабельным почти без затрат. Единственные разработчики, которые выступают против оператора идентификации, - это индивидуальные разработчики и люди, которые не работают в команде. По определению, люди, код которых не просматривается достаточным количеством глаз.there is no reasonable situation
это грубое искажение. Подумайте о (родных) типах JavascriptNumber
иString
. Их существование доказывает, что авторы Javascript имели в виду определенные варианты использования==
. Вы действительно думаете, чтоnew String('hi') === 'hi'
оцениватьfalse
очень ясно? Напишите фрагмент кода, который проверяет аргумент вашей функции на предмет'hi'
принятия и String, и String, и скажите мне, что это ясно.JSLint по своей природе более оборонительный, чем позволяет синтаксис Javascript.
Из документации JSLint:
источник
==
оператором.===
Это особый случай ... JSLint пытается сделать это , похоже , как с помощью==
так или иначе неправильно ... Впрочем, попробуйте это:var x = 4, y = new Number(4); if (x == y) {alert('Javascript depends on == just embrace it!');}
. У примитивных типов есть соответствующие классы, которые их заменяют (Number
,String
), а Javascript зависит от==
оператора, чтобы сделать сравнение естественным.Имейте в виду, что JSLint навязывает одному человеку представление о том, каким должен быть хороший JavaScript. Вам по-прежнему нужно руководствоваться здравым смыслом при реализации предлагаемых им изменений.
В общем, сравнение типа и значения сделает ваш код более безопасным (вы не столкнетесь с неожиданным поведением, когда преобразование типа не сделает то, что, по вашему мнению, должно).
источник
Тройное равенство отличается от двойного равенства, потому что помимо проверки того, являются ли две стороны одинаковыми значениями, тройное равенство также проверяет, что они имеют один и тот же тип данных.
Так
("4" == 4)
верно, тогда("4" === 4)
как ложно.Triple-equal также работает немного быстрее, потому что JavaScript не должен тратить время на преобразование каких-либо типов, прежде чем дать вам ответ.
JSLint намеренно нацелен на то, чтобы сделать ваш код JavaScript как можно более строгим с целью уменьшения неясных ошибок. Он выделяет подобные вещи, чтобы попытаться заставить вас кодировать таким образом, чтобы вы уважали типы данных.
Но преимущество JSLint в том, что это просто руководство. Как говорят на сайте, это обидит вас, даже если вы очень хороший программист на JavaScript. Но вы не должны чувствовать себя обязанным следовать его совету. Если вы прочитали то, что в нем говорится, и вы это понимаете, но уверены, что ваш код не сломается, то вы не обязаны что-либо менять.
Вы даже можете указать JSLint игнорировать категории проверок, если вы не хотите, чтобы вас засыпали предупреждениями, с которыми вы ничего не собираетесь делать.
источник
Цитата из http://javascript.crockford.com/code.html :
JSLint очень строгий, их 'webjslint.js' даже не проходит их собственную проверку.
источник
webjslint.js
отсутствия проверки - хотя большинство ошибок, которые я вижу сейчас, связаны с интервалом. Очевидно, что при рассмотрении JavaScript с использованием JSLint необходимо руководствоваться здравым смыслом и разумным суждением.always
автоматически лишает эту цитату мудрости. Умные программисты не догматичны. Они используют то, что лучше всего в данной ситуации. И они приветствуют и используют любой инструмент, встроенный в самое ядро языка, а не просто отвергают его с помощьюjust never touch it
. Итог: мой код короче (и не только из-за сохранения одного=
символа), поэтому мой сайт загружается быстрее, с меньшими затратами на пропускную способность, поэтому мой пользователь лучше обслуживается.Если хотите проверить на фальшивость. JSLint не позволяет
if (foo == null)
но позволяет
if (!foo)
источник
===
, что рекомендует JSLint.foo == null
проверяет наличие null или undefined.!foo
проверяет наличие null, undefined, 0 и пустой строки.Чтобы помочь объяснить этот вопрос, а также объяснить, почему NetBeans (из) 7.3 начал показывать это предупреждение, это отрывок из ответа на трекере ошибок NetBeans, когда кто-то сообщил об этом как об ошибке:
Рекомендуется использовать === вместо == в JavaScript.
Справка
источник
На самом деле это не может вызвать проблем, это просто совет. Возьми это или оставь. Тем не менее, я не уверен, насколько это умно. Вполне могут быть контексты, в которых это не представляет собой проблему.
источник