Poll: Semicolons in JavaScript

Personally I think the Google Javascript Style Guide has it right:<p>&#62; Relying on implicit insertion can cause subtle, hard to debug problems. Don't do it. You're better than that.<p><a href="http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Semicolons#Semicolons" rel="nofollow">http://google-styleguide.googlecode.com/svn/trunk/javascript...</a>

Readability is the single most important quality of a piece of code. Semicolons aid readability by eliminating ambiguity and ensuring that nobody ever has to spend even a second figuring out whether your code will do what it looks like it will do.<p>I add semicolons for the same reason I surround <i>if</i> blocks with braces, pad out blocks with whitespace, and avoid the ternary operator in all but the most trivial cases. If you ever find yourself dropped onto a line of my code by a debugger, chances are you'll be able to figure out exactly what's going on immediately.<p>At least that's the goal.<p>(more here: <a href="http://expatsoftware.com/articles/2007/06/getting-your-priorities-straight.html" rel="nofollow">http://expatsoftware.com/articles/2007/06/getting-your-prior...</a> )

Quote from Douglas Crockford (<a href="http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-the-good-parts%E2%80%9D-by-crockford" rel="nofollow">http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-...</a>):<p>When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. <i>I suppose it was a way of showing off</i> ...<p>Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes.<p>Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

For me it's a 'yes' based on the simple rule that explicit is always better than implicit. That sort of 'optimisation' seems to be really cool when you're just starting out in a language but in the long run it isn't worth it.<p>The first time you're bitten in the behind by a subtle bug after a couple of hours searching you've given up a hundredfold the time you have saved up to that point by not having to type those ;s. At that point people usually 'get it'.

When the curly-braces-syntax is replaced with proper sexp, I'm all for it. Until then, I prefer to keep the semicolons.

Yes, because JSLint tells me to do so, among other reasons.

fwiw, I often see this<p><pre><code> var bla = function() { //stuff //more stuff //some more }//no semicolon</code></pre>

Absolutely. Also, always use "var" in your variable declarations. I can't count how many times a scope issue bit me in the ass b/c of a missing "var"

Client side - yes. Server side - no. Server side code typically only runs through one interpreter, and is never minimized.

JS minimizers tend to remove all the newlines, so semicolons are often necessary if you use one.

The case for semicolons within javascript is one that you will hear a lot. You'll hear many cries for 'readability', 'eliminating random bugs' and 'helping minification'.<p>To begin with readability, i'm pretty sure that programmers are capable of working out the end of a line without the use of a semicolon: Scala has no such requirement of semicolons. Surely, the best way to ensure readability is, like in spoken language, to use common terms and expressions. Finding the obscure uses of the language to ensure the forceful requirement of a semicolon just seems petty and unhelpful. It is the equivalent of being overly prolix within a natural language, therefore limiting the ability to communicate.<p>The elimination of random bugs is a little more tricky to discern. Sure, there are occasional issues that can be caused by the lack of semicolons, for example (taken from the quoted text):<p>a = b + c (d + e).print()<p>But let's face it, if you're writing your javascript like that then you probably need to re-evaluate the your use of (d + e). After all, the majority of browsers now use javascript compilers that are more than capable of constant folding. Therefore meaning that:<p>a = b + c var f = d + e f.print()<p>should therefore be no less efficient and, on the side of readability, you could even name f to be something worthwhile.<p>The best minifiers (YUI and Google's Closure Compiler) are perfectly capable of minifying javascript without semicolons. If your minifier is having issues because you haven't inserted a semicolon, then—obviously—it's not doing its job properly.<p>In my writing of javascript, I very rarely use semicolons and the issues described have never come up. Often the expressions given as to why it is necessary are extreme and obscure to the point whereby using those expressions may not be the best policy. I'm not advocating the idea of never using semicolons (something i pretty much do), I'm just saying that the requirement for constant use is pointless.

It seems like semicolon insertion is an example of browsers being liberal acceptors of slop. Good that the rules are codified by ECMA, much like HTML5's error recovery parsing rules, but I wouldn't omit semicolons on purpose.

Let Crockford himself explain why 'Yes' is the right answer: <a href="http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s" rel="nofollow">http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s</a>

My comment on the subject:<p><a href="http://groups.google.com/group/nodejs/msg/de4630fa8953b183" rel="nofollow">http://groups.google.com/group/nodejs/msg/de4630fa8953b183</a>

yes, because the consistency removes it as a potential cause of bugs, and makes my code easier to debug by someone else.

Never make the browser guess.

Just do what Doug Crockford says, that definitely includes braces

I respectfully abstain from the vote.

Mind your own business!<p>It's none of your business how I choose to code my own projects.<p>If we're on the same project together, we can discuss it and decide on a style that works for everyone.<p>When I contribute to an OpenSource project, I adopt whatever style they have defined.<p>For my own projects, I have personally opted out of using unnecessary semicolons and brackets unless they improve maintainability or readability. But you don't have to know or care about that.