I personally don't care if one uses === or == as I don't remember any issue caused by ==, but I can see that so many of you are used to always use === that our code becomes inconsistent.
So, to avoid questions "why are you using == in random places?" or "why are you using ==?" we can make a rule to always use ===.
Although... I'd like to reply to the second question 馃槇
I'm always using === because I would like to be sure that I compare two the same types. Let's say, when I see === instead of ==, I'm sure that the developer knows what wants to do.
When I see ==, I'm wondering whether the code will work in edge cases. But also I know that sometimes we don't need to compare expression using === (e.g. typeof someVar == 'string' never returns false if someVar will contain a string).
Looks like a hard topic for discussion.
It's never really been an issue to me so whatever you do, it's gonna be fine 馃槢
I am afraid that there are places in code where == is on purpose and after such a change, we would have to refactor some code. Having both types of comparison is not a problem for me honestly, so I am against.
I think that such decisions, at this stage, should be based on a log of issues related to it, instead of a mere stylistic detail.
I think that such decisions, at this stage, should be based on a log of issues related to it, instead of a mere stylistic detail.
This is a kind of issue which either we resolve or no one will tell us that it's wrong. No one except us cares about the consistency of our code base. Also, we'll be judged by people who won't care to report it back to us.
I am afraid that there are places in code where == is on purpose and after such a change, we would have to refactor some code. Having both types of comparison is not a problem for me honestly, so I am against.
This happens when comparing to null or undefined. Those cases can be automatically fixed by ESLint (see https://eslint.org/docs/rules/eqeqeq).
While I understand that most of you don't care which operator is used, cause I don't care either, that wasn't actually the point. The point was about understanding how our code will be seen by others.
The point was about understanding how our code will be seen by others.
I'm pretty sure no one cares as long as the logic and structure are just fine.
Most helpful comment
I think that such decisions, at this stage, should be based on a log of issues related to it, instead of a mere stylistic detail.