Are there semicolon insertion dangers with continu

Question

Historically, I like to break expressions so that the "it's clearly incomplete" bias is shown on the continued line:

var something = foo + bar
    + baz(mumble);

This is an attitude that comes from working in languages which need semicolons to terminate expressions. The first line is already obviously incomplete due to no-semicolon, so it's better to make it clear to the reader that the second line is not complete.

The alternative would be:

var something = foo + bar +
    baz(mumble);

That's not as good for me. Now the only way to tell that baz(mumble); isn't standalone (indentation aside) is to scan your eyes to the end of the previous line. * (Which is presumably long, as you needed to break it in the first place.)*

But in bizarro JavaScript land, I started seeing people changing code from things that looked like the first form to the second, and warning about "automatic semicolon insertion". It certainly causes some surprising behaviors. Not really wanting to delve into that tangent at the time I put "learn what automatic semicolon insertion is and whether I should be doing that too" into my infinite task queue.

When I did look into it, I found myself semi-sure... but not certain... that there aren't dangers with how I use it. It seems the problems would come from if I had left off the + on accident and written:

var something = foo + bar
    baz(mumble);

...then JavaScript inserts a semicolon after foo + bar for you, seemingly because both lines stand alone as complete expressions. I deduced perhaps those other JavaScript programmers thought biasing the "clearly intentionally incomplete" bit to the end of the line-to-be-continued was better, because it pinpointed the location where the semicolon wasn't.

Yet if I have stated my premise correctly, I am styling my broken lines in a way that the ensuing lines are "obviously incomplete". If that weren't the case then I wouldn't consider my way an advantage in the first place.

Am I correct, that my way is not a risk for the conditions I describe of how I use line continuations? Are there any "incomplete seeming" expression pitfalls that are actually complete in surprising Ways?

To offer an example of "complete in surprising ways", consider if + 1; could be interpreted as just positive one on a line by itself. Which it seems it can:

But JSFiddle gives back 6 for this:

var x = 3 + 2
+ 1;
alert(x)

Maybe that's just a quirk in the console, but it causes me to worry about my "it's okay so long as the second line doesn't stand alone as complete expression" interpretation.

Answer 1

I started seeing people changing code from things that looked like the first form to the second, and warning about "automatic semicolon insertion"

That is rubbish. When you have an operator (on either line), there will be no ASI - see What are the rules for JavaScript's automatic semicolon insertion (ASI)?

Since both styles of placing the operator will work, both are commonly accepted and it boils down to personal/style-guide preference. You named some arguments already, once you have chosen either stick to it for consistency.

There is nothing "dangerous" about either, and honestly you shouldn't need to care about ASI. People get bitten by it only because a) they don't like semicolons and expect automatic insertion, but the next line is a syntactically valid continuation or b) they write object/array literals after a return statement in Allman style.

Answer 2

If you take some syntactically valid line and punctuate it with line breaks, automatic semicolon insertion will not apply (except in the narrow case of return, throw and very few other statements, listed below). ASI only occurs when there is absolutely no other way to interpret the code. Certainly, there is a way to interpret your multiline code as a single statement, because it is valid as a single line. In short, ASI is generally a tool of last resort in the parser's attempt to understand the program.

To cite ES5, the first case of ASI detailed in the spec occurs...

1. When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar...

But that case is naturally eliminated, because you had a grammatically valid line before you injected a newline into it. Thus, this case of ASI cannot apply to your case because it depends upon a span of code that is not syntactically valid without semicolons. You don't have that here.

(The other two cases don't apply either; the second case applies to the end of a program and the third case applies to continue, break, return, throw, and postfix ++/-- operators.)

The common problem people have with ASI occurs when an author has two lines which he expects will stand separately, but those two lines happen to cause no grammatical problem when understood as a single line. That case starts with two lines and they accidentally become one. Your cases is the inverse: you start with one line; it does not accidentally become two.