2 ms·
Even with a linter that can approve of that one use case, the problem with == these days is that it catches everyone off guard, and every developer who sees the
by hombre_fatal 4y ago
Even with a linter that can approve of that one use case, the problem with == these days is that it catches everyone off guard, and every developer who sees the code has to do the same "did they mean to use this or-- oh, it's for a null|undefined check" every single time.
Just because of that I've created an `isNil = (x) => x is undefined or null` function and banished == from my code.
== can lead to what we've jokingly called tollbooth code: code that can make every reader stop and pay a mental toll while they confirm that the writer did intend to write the code that way.
- eyelidlessness 4y agoThis is surprising to me! I/my team do use such a linter rule (non-strict equals errors for all cases except directly comparing to null), and I don’t even notice it while reading code because the linter is satisfied, and because it reads as (obviously, to me) correct. It never occurred to me that it could be so noticeable to others as to add any cognitive overhead. I’m not discounting that at all, to be clear, only that it’s not something I’d ever considered before now.
- fuckingbonkers 4y agoWe have banished it as well for this exact reason — the “toll” — if you want 1 more piece of anecdata.