6 ms·

Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure https://javascript.info/structure

by msie 6y ago

pknopf 6y ago
Yeah... There was a big push for that a while back. The JavaScript community can be silly.
stingraycharles 6y ago
https://news.ycombinator.com/item?id=2024328 https://news.ycombinator.com/item?id=2024328 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! :)
- wwweston 6y ago
  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.
  - randomsearch 6y ago
    “Explicit is better than implicit.”
- dagw 6y ago
  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.
  - Timpy 6y ago
    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.
    - dagw 6y ago
      Yea it was very weird. I think most people realized that his way wasn't the right way.
  - heja2009 6y ago
    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... https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language)
weeksie 6y ago
I've run into that in a few places and it always baffles me that people would intentionally choose to add even more gotchas to javascript. Don't get me wrong, I think aesthetics in code are important but not to the point of deliberately increasing the chance of hard to find bugs.
gtsop 6y ago
I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotcha" out of omitting semicolons. If for any reason you absolutelly can't have these in place, better be safe and use semicolons. Edit: for the "gotcha" explained in the link, prettier will automatically insert a semicolon before the array.
- ux-app 6y ago
  >I have yet to encounter a single "gotcha" out of omitting semicolons. keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case. I honestly don't see the logic.
  - oweiler 6y ago
    It just makes the code slightly easier to read. The semicolon is just noise.
    - burlesonK 6y ago
      Semicolons aren't noise; you've read the statement before you even get to them so how can they be noise? Noise would be type info added to languages that didn't have it before, such as TypeScript. Generics can get pretty gnarley too, when you have nested typing info involved.
      - goatlover 6y ago
        Noise as in new line already terminates. That’s one reason Python and Ruby code are cleaner to read.
    - dotancohen 6y ago
simplify 6y ago
I still don't use them :)
sneak 6y ago
I don't know whether I use them or not, to be honest (and I just finished a project in js). My code looks like whatever the almost-default (tab-width: 4) output of prettier is. It's nice to not waste a single braincycle on these things anymore.
- Jowsey 6y ago
  This. I just use an auto-formatter for the Standard style. If the Standard linter says it looks ok, it looks ok to me, and I move on with my day.
austincheney 6y ago
So what changed this? This was a hill that people were willing to die on.
flippinburgers 6y ago
Debate over one character whose presence in code has no downside other than that a subset of programmers get to feel less arrogant. Sometimes I cannot stand this industry.

Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure https://javascript.info/structure

by msie 6y ago

Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure https://javascript.info/structure

pknopf 6y ago

Yeah... There was a big push for that a while back. The JavaScript community can be silly.

stingraycharles 6y ago

https://news.ycombinator.com/item?id=2024328 https://news.ycombinator.com/item?id=2024328 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! :)

wwweston 6y ago
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.
- randomsearch 6y ago
  “Explicit is better than implicit.”
dagw 6y ago
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.
- Timpy 6y ago
  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.
  - dagw 6y ago
    Yea it was very weird. I think most people realized that his way wasn't the right way.
- heja2009 6y ago
  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... https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language)

weeksie 6y ago

I've run into that in a few places and it always baffles me that people would intentionally choose to add even more gotchas to javascript. Don't get me wrong, I think aesthetics in code are important but not to the point of deliberately increasing the chance of hard to find bugs.

gtsop 6y ago

I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotcha" out of omitting semicolons. If for any reason you absolutelly can't have these in place, better be safe and use semicolons. Edit: for the "gotcha" explained in the link, prettier will automatically insert a semicolon before the array.

ux-app 6y ago
>I have yet to encounter a single "gotcha" out of omitting semicolons. keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case. I honestly don't see the logic.
- oweiler 6y ago
  It just makes the code slightly easier to read. The semicolon is just noise.
  - burlesonK 6y ago
    Semicolons aren't noise; you've read the statement before you even get to them so how can they be noise? Noise would be type info added to languages that didn't have it before, such as TypeScript. Generics can get pretty gnarley too, when you have nested typing info involved.
    - goatlover 6y ago
      Noise as in new line already terminates. That’s one reason Python and Ruby code are cleaner to read.
  - dotancohen 6y ago

simplify 6y ago

I still don't use them :)

sneak 6y ago

I don't know whether I use them or not, to be honest (and I just finished a project in js). My code looks like whatever the almost-default (tab-width: 4) output of prettier is. It's nice to not waste a single braincycle on these things anymore.

Jowsey 6y ago
This. I just use an auto-formatter for the Standard style. If the Standard linter says it looks ok, it looks ok to me, and I move on with my day.

austincheney 6y ago

So what changed this? This was a hill that people were willing to die on.

flippinburgers 6y ago

Debate over one character whose presence in code has no downside other than that a subset of programmers get to feel less arrogant. Sometimes I cannot stand this industry.