// Statements can be terminated by ;
doStuff();
// ... but they don't have to be, as semicolons are automatically inserted
// wherever there's a newline, except in certain cases.
doStuff()
// Because those cases can cause unexpected results, we'll keep on using
// semicolons in this guide.
I haven't gotten much into Javascript yet, but is there any reason I would not terminate with semicolons? Without understanding which "certain cases" won't have them inserted automatically, relying on that feels like asking for trouble.
As a general case I recommend always terminating each statement with a semi-colon. Then it is explicit to the interpreter and other coders (and "other coders" includes "you six months later when you've forgotten most of what you did today") that you intended this to be the end of the statement and the next line to be the start of a new one.
Only ever leave the semi-colon out at the end of a line when you are explicitly using a multi-line statement to make your code more readable.
This makes your intent unambiguous in both cases; to the interpreter/compiler, to other tools, and to other humans.
My understanding is that the original decision was to make life easier for the programmer: if you forget, we'll put one in there for you. Myself, I'd rather be told that I made a mistake, then have it ignored, because how does the compiler know what I really wanted?
Instead of being told there's some problem with the code, it inserts a semi-colon into an arguably ludicrous location, and then gives you a differen error.
Would probably make compiler writers' jobs easier if they just spit out errors.
The actual reason that third function compiles, and the fourth does not, is that
{
x: 0
}
is a block statement with a label x. Try it in your console, it returns 0. The last one is an object literal outside an expression, which is a syntax error.
In addition to that, the return statement is 'restricted production' where the line break itself is a terminator, this has nothing to do with semi-colons or ASI.
Coming from a mostly C, Java and Perl background, I've got no personal issues with semi-colons, and often find myself adding them in languages where they're completely unnecessary, especially when switching back and forth.
Having said that, your argument could also apply to operator precedence and parentheses. Yet most languages implement this, and most users don't add them unless they're in doubt (more often with e.g. logical operators than arithmetic ones).
The rules aren't that complicated and the corner cases are (IMHO) a bit overrated. The way I see it, the more pressing reason would be the accepted JavaScript style, just like the positioning of braces.
Ah, the "minify" bug: forcing people to put statement separators into a line oriented language.
Think of semicolons in JS like colons in BASIC: they let you stack multiple statements on a line. Then, go learn what the language REALLY thinks is the end of a statement, which is not "I put in a semicolon".
Too bad JS doesn't use (an explicit) backslash for line continuation, rather than guessing when a line/statement was done :-(
Missing semicolons have more pitfalls than just minifiers being naughty.
return
someExpression
will parse out as:
return;
someExpression;
and you have assumption of function call in
x = y
(z).whatever()
which parses out as
x = y(z).whatever()
Nothing hint or lint wouldn't catch though. IMHO, you really need to be special to avoid explicitly writing out semicolons, but to each his own. I can maybe give it a point for unique style. :)
Wow, I got schooled. Did not realize rule 4 about lines starting with array subscript brackets or function argument parens. (regardless of the line's intent of perhaps being an array literal or simply starting with an expression to be evaluated early)
The sad reality, taking the second link to its satirical conclusion, is that all JS should be written on one line, with semicolons between statements. No guessing about the effects of line breaks if there aren't any. "I say we take off and nuke the entire site from orbit - it's the only way to be sure." :-)
How would semicolons have prevented the first of those misunderstandings?
-- Don't get me wrong, those are good cases to know what is going to happen. But I think you are making the case that semicolons provide a false security blanket, since the language can complete a line you meant to wrap, or, alas, merge 2 lines you meant to have separate.
I think shell (and a few other languages) actually got it right: 1 line = 1 statement, unless there is an explicit continuation.
