Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JSLint Expected '===' and instead saw '=='

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.

like image 604
Metropolis Avatar asked Sep 17 '10 13:09

Metropolis


People also ask

When do I get the “expected a string and instead saw” error?

When do I get this error? The "Expected a string and instead saw ' {a}'" error is thrown when JSLint encounters a comparison operator in which one of the operands is a typeof expression and the other operand is not a string literal. In the following example we are checking whether a variable is a string:

Is JSLint worth it?

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.

What are future reserved words in JSLint?

The third set is made up of identifiers that are also considered future reserved words, when they occur within strict mode code. JSLint will treat them in the same way as all of the previously listed reserved words, regardless of whether the code is in strict mode or not.

How to ignore JSHint warning-w024?

In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax. The identifier of this warning is W024 . This means you can tell JSHint to not issue this warning with the /*jshint -W024 */ directive.


8 Answers

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:

A == B AND
B == C

Doesn't really guarantees that:

A == C

For example:

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

The Strict Equals operator === is not really necessary when you compare values of the same type, the most common example:

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

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 undefinedsomething:

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
}
like image 59
Christian C. Salvadó Avatar answered Oct 02 '22 01:10

Christian C. Salvadó


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 ' \t\r\n' == 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

(foo != 0)

just say

(foo)

and instead of

(foo == 0)

say

(!foo)

The === and !== operators are preferred.

like image 28
Daniel Vandersluis Avatar answered Oct 02 '22 00:10

Daniel Vandersluis


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).

like image 39
Justin Niessner Avatar answered Oct 02 '22 01:10

Justin Niessner


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.

like image 30
Spudley Avatar answered Oct 01 '22 23:10

Spudley


A quote from http://javascript.crockford.com/code.html:

=== and !== Operators.

It is almost always better to use the === and !== operators. The == and != operators do type coercion. In particular, do not use == to compare against falsy values.

JSLint is very strict, their 'webjslint.js' does not even pass their own validation.

like image 26
Lekensteyn Avatar answered Oct 01 '22 23:10

Lekensteyn


If you want to test for falsyness. JSLint does not allow

if (foo == null)

but does allow

if (!foo)
like image 42
nano2nd Avatar answered Oct 02 '22 00:10

nano2nd


To help explain this question and also explain why NetBeans (from) 7.3 has started showing this warning this is an extract from the response on the NetBeans bug tracker when someone reported this as a bug:

It is good practice to use === rather than == in JavaScript.

The == and != operators do type coercion before comparing. This is bad because it causes ' \t\r\n' == 0 to be true. This can mask type errors. JSLint cannot reliably determine if == is being used correctly, so it is best to not use == and != at all and to always use the more reliable === and !== operators instead.

Reference

like image 36
EM-Creations Avatar answered Oct 02 '22 00:10

EM-Creations


Well it can't really cause problems, it's just giving you advice. Take it or leave it. That said, I'm not sure how clever it is. There may well be contexts in which it doesn't present it as an issue.

like image 32
Rushyo Avatar answered Oct 02 '22 01:10

Rushyo