[rgrannell1]

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.

[wallyhs]

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

[rgrannell1]

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.

[wallyhs]

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]

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]

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.

[jephir]

> 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]

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.

[IshKebab]

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

[BrendanEich]

See 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]

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]

I would undo the implicit conversion madness around == and !=.

[cozuya]

Is that really a big concern today where == is heavily frowned on by just about everyone due to the above and its slowness?

[BrendanEich]

== 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]

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.

[insin]

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.

[serve_yay]

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.

[esolyt]

Not harder than inserting a semicolon after every single line.