[freshhawk]

Relying on multiple different parser's implementation of the "auto semicolon insertion guesser" feature seems insane to me.

I'm a python/haskell guy too, I hate semicolons. But I'll put up with them because javascript needs them, it doesn't enforce them, but to write sane, maintainable code it really needs them.

Javascript is enough of a mess, this kind of thing just throws gas on the fire.

Have you published your branch? I think it would be very useful.

[spicyj]

JavaScript doesn't need them any more than Python does; they're used almost always simply because people don't know the (simple) rules of when statements end.

[nostrademons]

Or because people simply don't want to have to think about when statements end.

I know the semicolon insertion rules, because I'm obsessive-compulsive like that. In any team I lead, any software I write, and any open-source project I maintain, the coding standard will be "Terminate all your statements with semicolons."

Why? Because my job is to make less work for people, not more. I could give them a list of 4 rules, often each having a list of a half dozen+ tokens, and say "memorize these, or you're not a professional JavaScript programmer". Or I could say "Terminate your statements with semicolons", and there's one rule, the same as in many other languages, for them to memorize.

Other projects are free to do whatever they want with their coding standards, and if they want to make things complicated to show how 1337 they are or just because they think it looks pretty, fine. But of all the things you need to worry about to be a good frontend engineer, where to put the semicolons seems like the stupidest possible one.

[koningrobot]

Please read http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... again, especially the restricted production part. Using semicolons everywhere doesn't cover your ass in those cases. Granted, I've never ever encountered these, but still -- it's not as simple as you make it out to be.

[masklinn]

> Granted, I've never ever encountered these, but still -- it's not as simple as you make it out to be.

There's one and only one of these cases which I've seen (and I'd see) happen: `return`, for users of Allman, while that is completely nutty (just as Allman) some people will write:

    return
    {
        key: value
    };

even though they're defining an object literal not a scope. The result is returning immediately (undefined) and dropping the object in space.

`throw` would be really weird, it may happen with a labelled break or continue but I've yet to see those ever used at all (so a user of these probably wouldn't fuck up the label, plus that label would become a bareword which most static analyzers would trivially see) and postfix operators outside of continuated expressions (e.g. function calls) are unlikely to be split.

I've been bitten more often by not having inserted semicolons than by any of those.

[nostrademons]

That's covered by other really common coding standards, eg. "put braces and brackets on the same line as the token that comes before them", "don't add linebreaks unless necessary to stay under 80 chars", and "break after binary operators rather than before them".

The point's to minimize the amount of additional complexity that developers have to memorize. The set of rules above is very similar to what you see in pretty much any Algol-derived language; most developers already have it burned into their fingers. The set of rules necessary to code safely without semicolons is very specific to JavaScript, and to a very idiosyncratic style of JS at that.