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); 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.

user:	rgrannell1
created:	April 27, 2013
karma:	14