4 ms·

I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems.

I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems. It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all, and in some cases they make things worse (e.g. multi-line variable declarations). Also, "correct" use of semicolons in Javascript makes code less consistent (e.g. some function declarations end with a semicolon, others do not) whereas consistent use of braces is consistent. I certainly see far more bugs caused by an improperly inserted semicolon than an improperly omitted semicolon, but then I'm looking at jshinted code most of the time.

mistercow 13y ago
I used to believe as you do that semicolon issues were contrived and unlikely in JavaScript. But over the years I've been bitten by it enough times to know better. IIFEs are the most common source of semicolon problems: for(i = 0; i < 10; i++){ x = arr[i] (function(x) { setTimeout(function(){console.log(x)}) })() } A less common sort of pattern that I still use pretty often as a DRY measure: init() [x, y, z].forEach(function(a){ if(a.length > 5) { process(a) } }) This is clean and readable, and without semicolons it's completely wrong. Now sure, you can prepend semicolons to these specific cases, and that will work. Here's why I dislike that: 1. Those leading semicolons look weird. To the uninitiated, it looks like a typo, and that's a significant hazard if anyone else is going to touch your code. 2. While there are only a handful of special rules like this to remember, there's only one rule to remember if you don't rely on ASI.
- Tloewald 13y ago
  Good examples actually. (Makes me feel better about my ingrained semicolon habit.) Your examples will crash immediately and at the right spot though. The problems I see caused by excessive use of semicolons are often far weirder. That said, inadvertent errors caused by semicolon insertion are still more common and baffling (especially by people addicted to jslint who use a variable declaration idiom particularly easy to screw up with errant semicolons).
  - mistercow 13y ago
    The first example won't crash if the rvalue preceding the IIFE is a higher-order function (specifically, one that outputs a function). A relatively rare scenario, but a brutal one to debug. As for errors caused by extra semicolons, they can be weird, but I don't think I've ever actually hit one in practice. They'd also be a little easier to spot, since you tend to develop a reasonable instinct for where semicolons belong.
    - Tloewald 13y ago
      I'd say it's a lot easier to be suspicious of lines of code that start with '(' or '[' than find semicolons at the end of the wrong line. It's incredibly easy to put a semicolon where a comma is expected and vice versa. I do it all the time (usually causing an immediate error so it's not a huge deal).
raverbashing 13y ago
"It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all," Hence these are the cases where more time and resources will be wasted because of it. "I certainly see far more bugs caused by an improperly inserted semicolon" What would be an example of this? Because I've seen exactly zero bugs of this type (not counting typos, of course)
- Tloewald 13y ago
  var a = 17, b = 13; c = 5; (usually this will be across multiple lines) ...just overwrote c in a different scope. This kind of bug is common, idiomatic, baffling, and actually more likely among coders subscribing to javascript "best practices".
  - raverbashing 13y ago
    use strict? jshint / jslint your code? This doesn't justify playing a guessing game and skipping semicolons just because you think you know all the rules about not using them.
    - Tloewald 13y ago
      jslint won't stop it if there's a variable (c in this case) in the outer scope -- it's perfectly fine code as far as jslint is concerned. And jslint encourages that declaration style (actually encourages is too weak a word).

mistercow 13y ago

I used to believe as you do that semicolon issues were contrived and unlikely in JavaScript. But over the years I've been bitten by it enough times to know better. IIFEs are the most common source of semicolon problems: for(i = 0; i < 10; i++){ x = arr[i] (function(x) { setTimeout(function(){console.log(x)}) })() } A less common sort of pattern that I still use pretty often as a DRY measure: init() [x, y, z].forEach(function(a){ if(a.length > 5) { process(a) } }) This is clean and readable, and without semicolons it's completely wrong. Now sure, you can prepend semicolons to these specific cases, and that will work. Here's why I dislike that: 1. Those leading semicolons look weird. To the uninitiated, it looks like a typo, and that's a significant hazard if anyone else is going to touch your code. 2. While there are only a handful of special rules like this to remember, there's only one rule to remember if you don't rely on ASI.

Tloewald 13y ago
Good examples actually. (Makes me feel better about my ingrained semicolon habit.) Your examples will crash immediately and at the right spot though. The problems I see caused by excessive use of semicolons are often far weirder. That said, inadvertent errors caused by semicolon insertion are still more common and baffling (especially by people addicted to jslint who use a variable declaration idiom particularly easy to screw up with errant semicolons).
- mistercow 13y ago
  The first example won't crash if the rvalue preceding the IIFE is a higher-order function (specifically, one that outputs a function). A relatively rare scenario, but a brutal one to debug. As for errors caused by extra semicolons, they can be weird, but I don't think I've ever actually hit one in practice. They'd also be a little easier to spot, since you tend to develop a reasonable instinct for where semicolons belong.
  - Tloewald 13y ago
    I'd say it's a lot easier to be suspicious of lines of code that start with '(' or '[' than find semicolons at the end of the wrong line. It's incredibly easy to put a semicolon where a comma is expected and vice versa. I do it all the time (usually causing an immediate error so it's not a huge deal).

raverbashing 13y ago

"It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all," Hence these are the cases where more time and resources will be wasted because of it. "I certainly see far more bugs caused by an improperly inserted semicolon" What would be an example of this? Because I've seen exactly zero bugs of this type (not counting typos, of course)

Tloewald 13y ago
var a = 17, b = 13; c = 5; (usually this will be across multiple lines) ...just overwrote c in a different scope. This kind of bug is common, idiomatic, baffling, and actually more likely among coders subscribing to javascript "best practices".
- raverbashing 13y ago
  use strict? jshint / jslint your code? This doesn't justify playing a guessing game and skipping semicolons just because you think you know all the rules about not using them.
  - Tloewald 13y ago
    jslint won't stop it if there's a variable (c in this case) in the outer scope -- it's perfectly fine code as far as jslint is concerned. And jslint encourages that declaration style (actually encourages is too weak a word).