Как я могу остановить сообщение об ошибке Expected ‘===’ and instead saw ‘==’. от появления в jslint. Кажется, это не вариант.
Для тех, кто использует JSHint, вы можете отключить это предупреждение, установив для параметра JSHint значение eqeqeq значение false (обычно .jshintrc)
Если вы хотите быть хорошим гражданином и исправить свой код, чтобы использовать рекомендуемое сравнение вместо выключения предупреждения, убедитесь, что обе стороны сравнения используют один и тот же тип.
Это довольно жарко от прессы.
Дуглас Крокфорд только что добавил параметр «eqeq» к инструменту JSLint.
См. один из редакций от 12 июня 2011 года в GitHub:
Ad время написания не было обновлено на первой странице JSLint, но я протестировал его со следующим и не получил предупреждений == :
Recently I was running some of my code through JSLint when I came up with this error. The thing I think is funny about this error though is that it automatically assumes that all == should be ===.
Does that really make any sense? I could see a lot of instances that you would not want to compare type, and I am worried that this could actually cause problems.
The word «Expected» would imply that this should be done EVERY time. That is what does not make sense to me.
8 Answers 8
IMO, blindly using === , without trying to understand how type conversion works doesn’t make much sense.
The primary fear about the Equals operator == is that the comparison rules depending on the types compared can make the operator non-transitive, for example, if:
Doesn’t really guarantees that:
The Strict Equals operator === is not really necessary when you compare values of the same type, the most common example:
We compare the result of the typeof operator, which is always a string, with a string literal.
Or when you know the type coercion rules, for example, check if something is null or undefined something:
JSLint is inherently more defensive than the Javascript syntax allows for.
From the JSLint documentation:
The == and != operators do type coercion before comparing. This is bad because it causes ‘
‘ == 0 to be true. This can mask type errors.
When comparing to any of the following values, use the === or !== operators (which do not do type coercion): 0 » undefined null false true
If you only care that a value is truthy or falsy, then use the short form. Instead of
The === and !== operators are preferred.
Keep in mind that JSLint enforces one persons idea of what good JavaScript should be. You still have to use common sense when implementing the changes it suggests.
In general, comparing type and value will make your code safer (you will not run into the unexpected behavior when type conversion doesn’t do what you think it should).
Triple-equal is different to double-equal because in addition to checking whether the two sides are the same value, triple-equal also checks that they are the same data type.
So («4» == 4) is true, whereas («4» === 4) is false.
Triple-equal also runs slightly quicker, because JavaScript doesn’t have to waste time doing any type conversions prior to giving you the answer.
JSLint is deliberately aimed at making your JavaScript code as strict as possible, with the aim of reducing obscure bugs. It highlights this sort of thing to try to get you to code in a way that forces you to respect data types.
But the good thing about JSLint is that it is just a guide. As they say on the site, it will hurt your feelings, even if you’re a very good JavaScript programmer. But you shouldn’t feel obliged to follow its advice. If you’ve read what it has to say and you understand it, but you are sure your code isn’t going to break, then there’s no compulsion on you to change anything.
You can even tell JSLint to ignore categories of checks if you don’t want to be bombarded with warnings that you’re not going to do anything about.
Learning, cleaning up and updating a snippet I found on-line. I’ve been adding the somewhat new code «use strict»; and the way the snippet has been programmed is alike the below snippet;
Line 83 is pulling up the following error;
I know how to bracket this section however I’m not sure how the return is doing exactly, whether I should ass the < before the return and then close up after dragging = null; ?
This is also used as seen below;
1 Answer 1
Some automated tools consider placing a «naked» statement after a conditional (i.e. a statement not wrapped in a block) as bad practice.
Some even warn about multiple return statements or about writing if (x == 3) . instead of if (3 == x) . .
The original statement if (!dragging) return; is perfectly valid Javascript. If it’s more readable for you then just keep it that way and shut up that warning (there should be options to do that).