5 ms·

Not using semicolons has never be a problem for me. Just like everyone else I put them where they are needed. I don't put them where they aren't needed, becaus

Not using semicolons has never be a problem for me. Just like everyone else I put them where they are needed. I don't put them where they aren't needed, because they aren't needed and adding pointless syntax noise is dumb. If I forget to put them in somewhere they are needed, as anyone might do, I add them. No problems.

IshKebab 12y ago
The problem is that the rules for remembering where they are needed are hard to remember and error-prone.
- serve_yay 12y ago
  Sure, but in practical terms I feel like this never comes up. I just never have to deal with it and I write JS all day.
- BrendanEich 12y ago
  See http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons, hope it helps. The minimal semicolon style has only a few rules and many people find it easier to use and remember. I've used it but my C hacker habits go against it. It's a fine style. /be
  - aikah 12y ago
    Wow neat,yeah, js devs are going to call anyone out that doesnt use semicolons. Question : If you ever wanted 1 breaking change in the language, and somehow it would be possible (I know it wouldn't) what feature would you change ? Again just 1 feature.
    - BrendanEich 12y ago
      I would undo the implicit conversion madness around == and !=.
      - cozuya 12y ago
        Is that really a big concern today where == is heavily frowned on by just about everyone due to the above and its slowness?
        BrendanEich 12y ago
        == is not slow when types of operands (in typeof sense) match -- then it's equivalent to ===. You'll find a lot of == out there, or would if only Google code search were still up. Hey, I got to answer with the one thing I'd change. There are more than a few, and I had to pick. Losing the equivalence relation I had in the first ten days (apart from NaN != NaN of course) was my pick.
  - xtrumanx 12y ago
    I treat the issue like the issue of remembering the operator precedence rules or just using some extra parenthesis. Although I feel remembering where semicolons are needed is simple I still use them anyway for personal preference.
- esolyt 12y ago
  Not harder than inserting a semicolon after every single line.
- insin 12y ago
  I haven't used semicolons in JavaScript in places they're not necessary for years now - the only rule that's mattered in practice [1] is lines starting with [ or (. [1] This is a white lie - there is one additional vital ASI rule, but you already know it - don't put a linebreak after a return statement.
wallyhs 12y ago
> No problems. Except that there actually was a problem in this case as evidenced by the surrounding discussion. If the code had been written with a semicolon (or an if statement!) from the beginning, there never would have been a problem. You can argue that it wouldn't have been a problem if JSLint had been written "correctly" from the beginning, but every tool has bugs. Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code.
- jephir 12y ago
  > Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code. Leaving out semicolons actually makes the intent more clear. People run into problems with semicolon insertion when they try to create an unnamed expression, i.e: ["joe", "bob", "ann"].forEach(call); If you use a no-semicolon style, though, you must name all your expressions, which makes your intent more clear: var employees = ["joe", "bob", "ann"] employees.forEach(call)
  - wallyhs 12y ago
    When I mentioned intent, I was mostly referring to the use of an "if" statement vs. short circuiting in the referenced example. But I mean it in general. Every code base is different, of course. > If you use a no-semicolon style, though, you must name all your expressions. Thanks, I guess I missed that point.
- rgrannell1 12y ago
  I see the bug as JSLint's problem, not the code in question (though admittedly that was bad code). I agree that if your tooling requires semicolons you should be pragmatic and include them, but the reality is that parsers/minifiers are mostly built with the assumption that users won't always include semicolons, so that's a largely hypothetical situation. I definitely agree that you should code defensively, but I'm just not seeing why adding semicolons where ASI kicks in is a practical thing to do. I don't agree semicolons make the code more readable, but if there was such a case you should definitely add them. And everyone - not just people who omit non-ASI'ed semicolons - will forget to include them where needed eventually, but that's not even an especially painful bug. There are in my opinion more dangerous style choices that are ignored, like daisy-chained declarations. Writing var x = 1, y = 2, z = 3 is a pretty lousy idea, as it unnecessarily couples the meaning of several lines of code together, and makes code harder to edit. If you unthinkingly truncate the first line you get y = 2, z = 3 a pair of global assignments! That could be a really pernicious bug if you have supposedly 'local' variables sharing the name with an existing global object. It's better to be defensive and write var x = 1 var y = 2 var z = 3 if only for editability. My point is that the strong feeling on 'Semicolons' vs 'No Semicolons' is largely a product of focusing bias (http://en.wikipedia.org/wiki/Anchoring); http://en.wikipedia.org/wiki/Anchoring); to the extent that it is a problem either way it is a minor one, evidenced by the fact that similar stylistic dangers (see above) are either unfairly ignored or rightly not fretted over. tl;dr I don't see a practically valuable reason to use them where ASI does the work for you, semicolon vs semicolon is barely a practical issue either way.

IshKebab 12y ago

The problem is that the rules for remembering where they are needed are hard to remember and error-prone.

serve_yay 12y ago
Sure, but in practical terms I feel like this never comes up. I just never have to deal with it and I write JS all day.
BrendanEich 12y ago
See http://inimino.org/~inimino/blog/javascript_semicolons http://inimino.org/~inimino/blog/javascript_semicolons, hope it helps. The minimal semicolon style has only a few rules and many people find it easier to use and remember. I've used it but my C hacker habits go against it. It's a fine style. /be
- aikah 12y ago
  Wow neat,yeah, js devs are going to call anyone out that doesnt use semicolons. Question : If you ever wanted 1 breaking change in the language, and somehow it would be possible (I know it wouldn't) what feature would you change ? Again just 1 feature.
  - BrendanEich 12y ago
    I would undo the implicit conversion madness around == and !=.
    - cozuya 12y ago
      Is that really a big concern today where == is heavily frowned on by just about everyone due to the above and its slowness?
      - BrendanEich 12y ago
        == is not slow when types of operands (in typeof sense) match -- then it's equivalent to ===. You'll find a lot of == out there, or would if only Google code search were still up. Hey, I got to answer with the one thing I'd change. There are more than a few, and I had to pick. Losing the equivalence relation I had in the first ten days (apart from NaN != NaN of course) was my pick.
- xtrumanx 12y ago
  I treat the issue like the issue of remembering the operator precedence rules or just using some extra parenthesis. Although I feel remembering where semicolons are needed is simple I still use them anyway for personal preference.
esolyt 12y ago
Not harder than inserting a semicolon after every single line.
insin 12y ago
I haven't used semicolons in JavaScript in places they're not necessary for years now - the only rule that's mattered in practice [1] is lines starting with [ or (. [1] This is a white lie - there is one additional vital ASI rule, but you already know it - don't put a linebreak after a return statement.

wallyhs 12y ago

> No problems. Except that there actually was a problem in this case as evidenced by the surrounding discussion. If the code had been written with a semicolon (or an if statement!) from the beginning, there never would have been a problem. You can argue that it wouldn't have been a problem if JSLint had been written "correctly" from the beginning, but every tool has bugs. Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code.

jephir 12y ago
> Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code. Leaving out semicolons actually makes the intent more clear. People run into problems with semicolon insertion when they try to create an unnamed expression, i.e: ["joe", "bob", "ann"].forEach(call); If you use a no-semicolon style, though, you must name all your expressions, which makes your intent more clear: var employees = ["joe", "bob", "ann"] employees.forEach(call)
- wallyhs 12y ago
  When I mentioned intent, I was mostly referring to the use of an "if" statement vs. short circuiting in the referenced example. But I mean it in general. Every code base is different, of course. > If you use a no-semicolon style, though, you must name all your expressions. Thanks, I guess I missed that point.
rgrannell1 12y ago
I see the bug as JSLint's problem, not the code in question (though admittedly that was bad code). I agree that if your tooling requires semicolons you should be pragmatic and include them, but the reality is that parsers/minifiers are mostly built with the assumption that users won't always include semicolons, so that's a largely hypothetical situation. I definitely agree that you should code defensively, but I'm just not seeing why adding semicolons where ASI kicks in is a practical thing to do. I don't agree semicolons make the code more readable, but if there was such a case you should definitely add them. And everyone - not just people who omit non-ASI'ed semicolons - will forget to include them where needed eventually, but that's not even an especially painful bug. There are in my opinion more dangerous style choices that are ignored, like daisy-chained declarations. Writing var x = 1, y = 2, z = 3 is a pretty lousy idea, as it unnecessarily couples the meaning of several lines of code together, and makes code harder to edit. If you unthinkingly truncate the first line you get y = 2, z = 3 a pair of global assignments! That could be a really pernicious bug if you have supposedly 'local' variables sharing the name with an existing global object. It's better to be defensive and write var x = 1 var y = 2 var z = 3 if only for editability. My point is that the strong feeling on 'Semicolons' vs 'No Semicolons' is largely a product of focusing bias (http://en.wikipedia.org/wiki/Anchoring); http://en.wikipedia.org/wiki/Anchoring); to the extent that it is a problem either way it is a minor one, evidenced by the fact that similar stylistic dangers (see above) are either unfairly ignored or rightly not fretted over. tl;dr I don't see a practically valuable reason to use them where ASI does the work for you, semicolon vs semicolon is barely a practical issue either way.