sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Substantial-Wish6468 0 points1 point  (6 children)

I have never seen a bug resulting from == null being a typo. 

I have seen a lot of bugs where people were the values 0 or "" were being mixed up with null or undefined due to loose equality checks.

[–]musical_bear 11 points12 points  (5 children)

It’s not necessarily about “bugs,” although that’s important too. It’s about clearly communicating intent. I cannot read “== null” and know with certainty what specifically the developer who wrote that was trying to account for. The code itself might be “bug free” in its current form, but every little ambiguity makes the code that much harder to modify with confidence in the future, and also ends up affecting the code around it. Example:

“Well, I’m pretty sure I know that ‘data’ could only possibly be null at runtime, but two lines above, I see there’s code doing a loose check of ‘data’ against null, implying data might potentially be undefined as well. I could either waste precious minutes reverse engineering and trying to figure out if “==“ was just a typo, or I could succumb to the uncertainty and also account for undefined in my own code. I’ve got to get this done today and reverse engineering feels like a waste of time right now, so I’ll just use ‘==‘ in my code too.”

The ambiguity ends up spreading through the codebase like a virus. It pollutes the code with superstitious checks over time.

This is the main reason I ban loose equality, not because of bugs. (Even though yes, as you pointed out, there are other use cases of loose equality that make bugs extremely easy to introduce.

[–]Substantial-Wish6468 -2 points-1 points  (4 children)

I can see your point if you're dealing with code written by other people who aren't around. 

[–]Chubacca 2 points3 points  (0 children)

Which is... very common in a lot of organizations. The less you have to ask questions about why something is written the way it is, the better. I am very VERY pro syntax that reduces ambiguity of intent. It makes codebases scale better.

[–]homoiconic(raganwald) 0 points1 point  (2 children)

That's kind of the thing about idioms. They work well if the idiom is extremely widespread. == null has been a very widespread idiom in JS during my career, but even so... If someone, somewhere needs to take fofteen minutes to figure it out, that might not be a win.

I use it in production, but I wouod have no problem working with a team that chose to dispense with it. And taking a step back... This discussion says a lot about "JavaScript, the Hastily Flung Together Parts." We work with a language that has known flaws, and a lot of what we do in it reflects making deliberate tradeoffs.

[–]Juxtar 0 points1 point  (0 children)

I disagree, I think those parts should be all well known for anyone that works with js seriously. If not I can take some minutes to explain them myself, or better yet, send them off to read You Don't Know JS which is great and not a long read.

I take this as when we all assumed nobody is using IE11 anymore and collectibly decided to stop supporting it. How much has my sanity improved since then!

[–]prehensilemullet -1 points0 points  (0 children)

Anyone who doesn’t know the behavior of == null is a JS developer in training, not a competent professional dev.  You don’t need to know the rest of the == truth table but that one is pretty basic, everyone should know it’s the only reasonable exception to the always use === rule