3 ms·

One thing I dislike is superfluous code under the guise of best practices or defensive programming. Here's an opinion of mine I've found to be controversial: In

by windows2020 5y ago

One thing I dislike is superfluous code under the guise of best practices or defensive programming. Here's an opinion of mine I've found to be controversial: In JavaScript, I don't like to use ===/!== unless I'm actually operating on operands that can be multiple types.

bigDinosaur 5y ago
Hard disagree. Many more bugs are caused by the type coercion of '==' than are caused by people adding verbosity with the use of a single additional character. It also is way easier to read code when you don't have to worry about the type coercion possibilities of JS's double equals operator. Type coercion should be opt-in and not the default, if there are good reasons for it existing at all, since it inherently makes things more complicated. Imagine how absurd this position would be if there was an equivalent with the less/greater than operators...
- deleted 5y ago
  [deleted]
Gunax 5y ago
Hmm, just curious why that would make it better. I think it's hard to justify because the cost is so low (it's an extra character, and possibly some confusion) but can have a big downside if the unexpected happens.
beart 5y ago
What happens if the code changes and something you thought was restricted to a single type, isn't anymore? Do you have to go through and update every equality check?
BigJono 5y ago
I think it's controversial because you have a really good point but your example kind of goes against your point rather than supporting it. '===' is a single operator in JS, just as '==' is. It's only superfluous in terms of character count (which barely matters at all), as opposed to token count or actual complexity. I'd argue that in the important metrics, '==' is actually more superfluous, in that it has a broader scope of functionality than '==='. When you use '==' to do an equality check you're essentially invoking something that does the check, but also does a bunch of implicit type conversion and checking between types, none of which you actually care about at all. I'm also not a fan of 'defensive programming', I think people fuck a lot of perfectly good code up trying to read the tea leaves about how other devs are going to poorly interact with it in the future. But using '===' is like saying "I just want to check equality". It's not adding something for the sake of defense (other than the single character), it's removing something useless for the sake of removing something useless. Which is a good thing for maintainability and bug prevention yada yada, but it also feels nice to do as a dev. That's why you see very few people arguing against '===' as a best practice, because incentives are mostly aligned in this case. It's not really like a lot of the other examples where something is seen as a 'best practice' in spite of being something that devs hate doing.
fhars 5y ago
You really prefer this https://javascriptwtf.com/wtf/javascript-holy-trinity https://javascriptwtf.com/wtf/javascript-holy-trinity to a well defined equality operator?
- lloydatkinson 5y ago
  Agreed, it’s crazy they would want a coercive check in a dynamic language. I’m certainly glad ESLint will enforce sanity and ban ==

bigDinosaur 5y ago

Hard disagree. Many more bugs are caused by the type coercion of '==' than are caused by people adding verbosity with the use of a single additional character. It also is way easier to read code when you don't have to worry about the type coercion possibilities of JS's double equals operator. Type coercion should be opt-in and not the default, if there are good reasons for it existing at all, since it inherently makes things more complicated. Imagine how absurd this position would be if there was an equivalent with the less/greater than operators...

deleted 5y ago
[deleted]

Gunax 5y ago

Hmm, just curious why that would make it better. I think it's hard to justify because the cost is so low (it's an extra character, and possibly some confusion) but can have a big downside if the unexpected happens.

beart 5y ago

What happens if the code changes and something you thought was restricted to a single type, isn't anymore? Do you have to go through and update every equality check?

BigJono 5y ago

I think it's controversial because you have a really good point but your example kind of goes against your point rather than supporting it. '===' is a single operator in JS, just as '==' is. It's only superfluous in terms of character count (which barely matters at all), as opposed to token count or actual complexity. I'd argue that in the important metrics, '==' is actually more superfluous, in that it has a broader scope of functionality than '==='. When you use '==' to do an equality check you're essentially invoking something that does the check, but also does a bunch of implicit type conversion and checking between types, none of which you actually care about at all. I'm also not a fan of 'defensive programming', I think people fuck a lot of perfectly good code up trying to read the tea leaves about how other devs are going to poorly interact with it in the future. But using '===' is like saying "I just want to check equality". It's not adding something for the sake of defense (other than the single character), it's removing something useless for the sake of removing something useless. Which is a good thing for maintainability and bug prevention yada yada, but it also feels nice to do as a dev. That's why you see very few people arguing against '===' as a best practice, because incentives are mostly aligned in this case. It's not really like a lot of the other examples where something is seen as a 'best practice' in spite of being something that devs hate doing.

fhars 5y ago

You really prefer this https://javascriptwtf.com/wtf/javascript-holy-trinity https://javascriptwtf.com/wtf/javascript-holy-trinity to a well defined equality operator?

lloydatkinson 5y ago
Agreed, it’s crazy they would want a coercive check in a dynamic language. I’m certainly glad ESLint will enforce sanity and ban ==