3 ms·
Here's the rules you need to follow if you use semicolons: 1) Use a semicolon. 2) There is no rule 2. EDIT: This may seem flippant but the point is that huma
by pluma 11y ago
Here's the rules you need to follow if you use semicolons:
1) Use a semicolon.
2) There is no rule 2.
EDIT: This may seem flippant but the point is that humans make mistakes and the more rules you have to obey, the more mistakes they will make. Especially beginners.
ASI (automatic semicolon insertion) and double-equals (weak comparison vs triple-equals strict comparison) aren't bad because they don't work, they are bad because they allow for unnecessary mistakes in return for a minimal reduction of characters you need to type.
Despite all the rationalizations, the primary reason some programmers prefer to rely on ASI is purely aesthetics. That's okay, but there's no point in trying to construct artificial arguments to defend that preference.
If a future version of the language somehow manages to eliminate the need for those rules, I'll be the last person to tell you to stick to your semicolons. Until then, it's still a voluntary handicap.
- spion 11y agoEven if you use semicolons, you still need the extra rule about return/throw statements. Otherwise the following will surprise you: return { property: value }; (Whats the value returned? Its `undefined`) Therefore, "Use a semicolon" is insufficient. Or rather, its about as sufficient as "Don't start a line with (". Which means that the rule(s) for using semicolons are no more complex than the rules for not using them. This is precisely why "follow these simple rules" is not enough. I believe that us programmers would really benefit if we stopped following and perpetuating best practices without understanding (and explaining) the reasons behind them very throughly. If you want less cognitive overload, use a language with less warts, or a language with a type system. Lint-like rules that don't come with a reason are useless and result in a false sense of security