Since a few months, my IDE (WebStorm) highlights JavaScript regular equality operators with the following warning:

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 !=.

I am aware of the different behavours of both operators and I tend to use them because of their different behavour, eg. for lazy type conversions:

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

However, the IDE is adding warnings to all occurences of ==, so the above does not feel right anymore. I'm could convert all these parts into something much less readable:

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

Is this really the way to go; or should I rather ignore/disable these warnings?

Since a few months, my IDE (WebStorm) highlights JavaScript regular equality operators with the following warning:

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 !=.

I am aware of the different behavours of both operators and I tend to use them because of their different behavour, eg. for lazy type conversions:

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

However, the IDE is adding warnings to all occurences of ==, so the above does not feel right anymore. I'm could convert all these parts into something much less readable:

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

Is this really the way to go; or should I rather ignore/disable these warnings?

• javascript
• type-conversion
• operators
• warnings
• equality

• 1 == is only good for if(x==null) since it hits undefined too – dandavis Commented Jun 29, 2017 at 22:57
• 1 i.e. not "good" really – Lightness Races in Orbit Commented Jun 29, 2017 at 22:59
• 1 @BoundaryImposition: how is that not good? I've never wanted to split hairs between null/undefined; both mean "nope". Why type more than needed to be legible; let the piler do to the work. – dandavis Commented Jun 29, 2017 at 23:00
• 1 @dandavis What is the difference between null and undefined in JavaScript? – castletheperson Commented Jun 29, 2017 at 23:11
• 1 It's not helpful to mark this question as a duplicate of a question that was closed for being not constructive. It's essentially saying this question is not constructive. – RobG Commented Jun 29, 2017 at 23:19

2 Answers 2

Yes, this has been best practice for almost two decades.

The warning is quite clear (even explaining why it's in place), and you'll find the same advice in your JavaScript books as well as widely across the web.

So, I can't prehend why you'd consider ignoring or even disabling it.

You can find more information on when to pick == and when to pick === here:

• When is it OK to use == in JavaScript?

I would argue that any form of type coercion, if unexpected for types that may not be known at runtime (like any dynamic language) is bad practice.

For example, these are both truthy:

 "0" == false
 "0"

While this is falsey:

 false