Comparison may cause unexpected type coercion... Follow
This seems unnecessary as I've had to fix code where === or !== was used everywhere (as "good practice" supposedly) because the code would fail when it encountered an unexpected datatype even though all that mattered was the value...
For instance, say you get in XML or JSON from a request response, and your if statement is `if(value === 86)` but the XML/JSON value is string '86', the processing will fail even though the value matched and that's all that was wanted from the response. For the === to work properly, you'd either have to type '86' or convert the value to an integer... which is far more coding than simply deleting an =.
In some case I've seen datatype convert through various processes or functions or even languages, and while the value remains the same, it will not be seen as the same by this "good practice". It's as good as being completely different in this case.
Please sign in to leave a comment.
The IDE does not force you to use this or that coding style. You can disable this inspection completely, or suppress it for the statements where type coercion is used intentionally
I'm saying the warning is overly broad, and its advice is probably not good practice in PHP with its auto-conversion, as usually the value matters but not the datatype, and checking datatype when it's not necessary can cause failure in real-world scenarios.
to suppress this warning unset this checkbox:
official help page:
Is it possible to suppress a specific statement? Can I use some kind of a comment mark-up if I want to use the type coercion somewhere?
This can be done with Alt+Enter - see https://www.jetbrains.com/help/webstorm/2019.3/disabling-and-enabling-inspections.html#suppress-in-editor
Nice, thank you!
I have found this warning particularly useless and very annoying in cases similar to the following example:
How can this possibly cause a type coercion? 'JohnDoe' is clearly a string and user will either be equal to it or not. There is no way in hell that the JS interpreter will be confused by this ... and it's a case insensitive comparison. There is nothing much to it. Unless there is something super obvious that I am not noticing.
Please correct me if I am wrong because I cannot afford disabling this inspection ... it is often very helpful.
As it's written above, you can suppress inspection for current statement only by adding