Amusingly, I agree with your premise but not really your conclusion. Adding a semi-colon is like adding parentheses. But I think redundant parentheses add visual clutter--unless I have a very complicated expression, I leave them off. (Maybe it's the Haskell code style rubbing off on me...)

So I actually think that 1 + 2 * 3 is better than 1 + (2 * 3). I usually find reading a line with less stuff easier, so I prefer the shorter between two equivalent expression.

Besides, adding a semi-colon is more like surrounding the whole expression with parentheses rather than just grouping. And you would never write (1 + (2 * 3)). And yet that also says, loud and clear, the same thing!

I've used some languages with optional semi-colons--Python and Haskell, for example. I've never thought that missing them made the code less readable--it's always been the opposite. Going back to Java and having to use semi-colons everywhere becomes increasing annoying as I grow more acclimated to languages without.

In short, I see where you're coming from but don't really agree.

So in this case:

    var value = x + fn
    (y).burp()

Is it obvious that there is a missing semi-colon at the end of line 1? The code is technically correct without it (not that I approve of it). You can assume it's wrong, but it's just a guess.

If your code is in no-semi-colon style, there is no ambiguity, you can be 100% sure that this is a mistake: there always should be a semi-colon guarding that parenthesis, regardless of intent:

    var value = x + fn
    ;(y).burp()

It's about removing ambiguity and visual clutter with a simple set of rules.

How many JS programmers know the difference between a function expression or declaration, and the semi-colon that should follow or not? You're dependent on a linter. Following the no-semi-colon rules makes your intentions clear in every case, without machine validation.

I don't follow this argument. Putting a semicolon at the end of every statement, regardless of what follows, seems to be an even easier way to avoid making this bug.

I think the usual semi-colon-less style is to put a semi-colon in front of lines beginning with parentheses (and only those lines). This is the one potential problem area if you don't have semi-colons everywhere, so you can avoid almost all (or maybe actually all) problems just by prepending a semi-colon to those lines.

I think Ricardo's point is that this style (having a semi-colon only before parentheses at the beginning of the line) makes your intentions more explicit.

The full list is [(+*/-. (basically parenthesis, array/property acessor, and any math)

> Putting a semicolon at the end of every statement

Sounds like a viable strategy - but you have to parse where every statement ends in your head. The situations where you don't end a line with a semi-colon are more numerous than the rules you need to write semi-colon-free code. Besides, if it's so simple, why not leave it to the interpreter?

It's trivial to parse when statements end in my head, because I write code in a structure that makes it unbelievably clear where statements begin and end (with or without semicolons.) Knowing that is of prime importance to human readability, so it has to be dead obvious or the code sucks.

I'd love to leave it to the interpreter, but the interpreter doesn't put a semicolon at the end of every statement for me, as I write them naturally. It puts a semicolon at the end of... most statements.

This is a silly example because it's so simple. E.g. You can just write 2*3+1, which is easier to read. Regardless, I'd wonder why you put the parenthesis there, as if it were some odd hack or workaround for some obscure bug.

Sure, it's a simple example. How about:

    destPoint.x + offset.x * diameter

vs

    destPoint.x + (offset.x * diameter)

The longer the variable names the harder it is to visually parse the order of operations. At least for my brain.

This whole thread is arguing about style, IMO. I'm just offering my explanation why this style makes more sense to me.