I don't understand the (anti) hype about type coercion and the '==' operator. I get a faintly cargo-culty vibe from people when they talk about '===' vs '==', since the examples are usually very strange things that I never see in production. I'm not an expert in JavaScript but I've written a fair amount and a couple largish programs and I've never been bitten by a type-coercion bug involving '=='.
The weird subtle bugs I see are usually associated with me using "for (i in a)" for arrays instead of the more ugly C style for loop, which results in "i" being a string (which usually doesn't matter except when using "+" which is sometimes addition and sometime string concatenation).
So, is '==' really that bad? Has anyone seen (otherwise) well-written production code fail because of '==' vs '==='?
I spent a lot of time trying to track down bug in a system once (in php) that was caused by this. I don't remember the exact problem but basically it did something like "if(x == 5)" which is true for both 5 and "5" - but later in the code it was important that the value was actually 5 and not "5".
But I think the main thing is that for people beginning programming it's better to have less flexibility. In most production system it might not matter that 5=="5" but it's important for beginners to understand how different types work. And it helps give a better insight into how if statements, and boolean logic in general, work.
I agree - in fact the problem was solved by removing some unnecessary type-checking code.
The point I was trying to make is that it's easier to learn the basics of types and logic in a strict system. Implicit type conversion and polymorphism can easily result in misunderstandings when you've just started learning to program.
Again. These are classes for _beginners_. I'm not suggesting that you should never learn these things. They should also learn functional programming, estimating how algorithms perform, concurrent programming, binary trees, and a few hundred other things.
But Programming is not something you master overnight.
You need to understand that 2+2=4 before you can understand that 2+i^2=1.
You are correct, but in that case it's not the question of what is easier, but what is necessary. "Easier" implies that there is a choice between comparable options, not that one is the prerequisite for the other.
Yes, but using === would have identify such bugs by causing failure of the test rather than running the code for "is true" and getting odd results. The conditional code simply not running will often make the bug (one of the values not being of the expected type) easier to trace than a calculation resulting in 51 instead of 6 ("5"+1 rather than 5+1) at some point later.
You can fix such a bug in two ways: "manually" coerce the values when used, or make sure they get converted to the right type as early as possible. I find tha ltter, along with using === except where you really must have a more flexible comparison, to be the better approach. And if I mistype and skip a = I end up with == instead of = (which would cause a different class of bug!)
The weird subtle bugs I see are usually associated with me using "for (i in a)" for arrays instead of the more ugly C style for loop, which results in "i" being a string (which usually doesn't matter except when using "+" which is sometimes addition and sometime string concatenation).
So, is '==' really that bad? Has anyone seen (otherwise) well-written production code fail because of '==' vs '==='?