Here’s an example great bike shed discussion from ~10y ago about whether or not to use semicolons with JavaScript.
“If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.”
Something I always thought was interesting about that argument is how a similar line of reasoning could apply to the `==` and `===` comparison operators.
Just about anyone who's ever written JS probably knows about the heavy lean towards "always use `===`". And it's not without good reason, because there are more than handful of not-entirely-intuitive implicit coercions/comparison corners associated with `==`. Personally, I think it's OK to use it, but I understand that it requires knowing the rules associated with use and most of all comes with the overhead of keeping them in mind when you do so. Most of the time it will be OK if you know even most of the rules. Sometimes it will not be OK. More often the overhead will cost you attention to other things. Some people have made the call "wouldn't it be simpler if we just did strict comparison and saved our attention for other things?" and while it's not my first choice, I can understand and respect it.
The statement termination thing strikes me as pretty much the same. Sure, if you know the rules, you can do it freely. But it takes something explicit that you don't have to think about and turns it into something implicit that you do. It isn't going to be a problem most of the time, but sometimes it will not be OK. A little more often the overhead will cost you attention to other things. Following the rule that semicolons terminate statements hasn't ever cost me anything.
The weird thing in my experience was the frequent overlap between antisemicolonists and always===ists. My theory is that mostly these people came from Ruby and Python, liked less punctuation for subjective aesthetic reasons, and didn't actually know the coercion rules well or particularly like JS, but that's speculation.
Reminds me of a CS teacher for our intro Haskell course at university who would dock points for unnecessary use of parentheses, since he considered that it showed we didn't understand order of operations or how our program was parsed.
The programming language Occam, in its time the primary language to program Transputers, did not have operator precedence, so you had to use parentheses for anything.
It was a huge pain, but probably still better than avoiding the edge cases of what you describe...
That sounds like a bad professor. It doesn't cost anything to add parenthesis for clarity. I enjoy well written code but we're not writing literature here, it's okay to be explicit.
Here’s an example great bike shed discussion from ~10y ago about whether or not to use semicolons with JavaScript.
“If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.”
Those were the fun days! :)