3 ms·

> 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

by 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.
- wallyhs 12y ago
  I am - I think - looking at this from a safe-by-default perspective. Everyone will forget to include a semicolon eventually as you pointed out, but shouldn't your default strategy be the safest one? Maybe I am missing something. There are obviously cases where missing semicolons do cause problems. Is there a situation in which adding a semicolon where allowed causes problems or increases the chances of introducing a bug in the future?
  - BrendanEich 12y ago
    What's the default, though? If I try adding semicolons and over-do it, probably I'm ok. But I might make an empty statement while loop body -- an iloop. And being human, I will inevitably leave a crucial semicolon out. I agree with the parent post. You can go wrong with either C-like or "NPM house" style. Linters are important, moreso in JS than in modern C and C++ (back to the future; I remember old C, which was wildly permissive). Pick your poison, study it well and dose carefully.
    - wallyhs 12y ago
      Now I know where my bias comes from: I did not consider going wrong with semicolons in C. Perhaps that is because C is my oldest friend. You are of course correct that the C style is not perfect either. Thanks for the reply.

by wallyhs 12y ago

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.

wallyhs 12y ago
I am - I think - looking at this from a safe-by-default perspective. Everyone will forget to include a semicolon eventually as you pointed out, but shouldn't your default strategy be the safest one? Maybe I am missing something. There are obviously cases where missing semicolons do cause problems. Is there a situation in which adding a semicolon where allowed causes problems or increases the chances of introducing a bug in the future?
- BrendanEich 12y ago
  What's the default, though? If I try adding semicolons and over-do it, probably I'm ok. But I might make an empty statement while loop body -- an iloop. And being human, I will inevitably leave a crucial semicolon out. I agree with the parent post. You can go wrong with either C-like or "NPM house" style. Linters are important, moreso in JS than in modern C and C++ (back to the future; I remember old C, which was wildly permissive). Pick your poison, study it well and dose carefully.
  - wallyhs 12y ago
    Now I know where my bias comes from: I did not consider going wrong with semicolons in C. Perhaps that is because C is my oldest friend. You are of course correct that the C style is not perfect either. Thanks for the reply.