6 ms·
This made me gag, years ago: // Statements can be terminated by ; doStuff(); // ... but they don't have to be, as semicolons are automatically inserte
by a3n 11y ago
This made me gag, years ago:
// 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.
- wlesieutre 11y agoI 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.
- a3n 11y agoMy 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? Here's a good one: http://stackoverflow.com/questions/18986144/javascript-compile-error http://stackoverflow.com/questions/18986144/javascript-compi... 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.
- ricardobeat 11y agoThe 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.
- ohitsdom 11y ago> Would probably make compiler writers' jobs easier if they just spit out errors. If this is your preference, JSLint has you covered. Really, every JS developer should be using a linter and tweak it to fit their coding preferences.
- dspillett 11y agoAs 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.
- mhd 11y agoComing 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.
- untog 11y agoI don't, simply because I don't need to. I'm aware there are edge cases to that, but they're usually edge cases caused by doing very odd things.
- Roboprog 11y agoAh, 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 :-(
- synthmeat 11y agoMissing 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. :)
- Nadya 11y agoOnly evil people put their return value on a second line... Regardless: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... Although to be fair: http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/ http://benalman.com/news/2013/01/advice-javascript-semicolon...
- Roboprog 11y agoWow, 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." :-)