4 ms·
I still use it for null/undefined checks, because it’s almost always what’s intended/expected. I was surprised to find out recently that this is even a remotely
by eyelidlessness 4y ago
I still use it for null/undefined checks, because it’s almost always what’s intended/expected. I was surprised to find out recently that this is even a remotely controversial take.
I do try to use the newer language features like nullish-coalescing and optional chaining to make the check less necessary, but sometimes it makes more sense (clearer code, less unnecessary code execution) to check for null/undefined and return early.
- hombre_fatal 4y agoEven 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.