For those unfamiliar with the matter, Javascript allows semicolons to be omitted sometimes, see:
http://inimino.org/~inimino/blog/javascript_semicolons
Update: This poll was started as a result of a discussion on the node.js mailing list:
http://groups.google.com/group/nodejs/browse_thread/thread/35810f231cb289aa
> Relying on implicit insertion can cause subtle, hard to debug problems. Don't do it. You're better than that.
http://google-styleguide.googlecode.com/svn/trunk/javascript...
I continue to use them in my code.
return { a : true }
and
return { a : true }
are different and can cause many problems.
I add semicolons for the same reason I surround if 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.
At least that's the goal.
(more here: http://expatsoftware.com/articles/2007/06/getting-your-prior... )
I always use semicolons in js.
I love the ternary operator on short bits of code though.
foo(something==null?somethingElse:something);
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 suppose it was a way of showing off ...
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.
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?
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'.
I don't really get what you call implicit when you terminate statements with semicolons instead of linebreaks... ... Ok, I get what you're hinting it: there are some (very) few exceptions. However, I cannot see where there is any 'optimisation' in using linebreaks instead of semicolons. You better need to explain why someone should use both linebreaks _and_ semicolons, when only using linebreaks is actually as good as well.
Basically, it's just a matter of style. Aside from a few exceptions (e.g. described in http://inimino.org/~inimino/blog/javascript_semicolons), linebreaks terminate a statement. If you stick with writing only one statement per line, I don't see what's so implicit with it. Rather terminating a statement both with a line break and a semicolon is a tautology, and hence introduces unnecessary redundancy.
The actual question is, whether one can require that developers know the (maybe a handful) exceptions where a line break doesn't terminate a statement. I have decided (for myself) that I can require that knowledge, as it really comes down to only a few exceptions (that I believe are easy to remember).
But, of course, I'm aware that one can also come do another reasonable conclusion.
The only important thing is that people make a concious decision about the issue at all. The importance of this increases with the number of people that are working together on a particular project.
Here a link to another article discussing that issue: http://mislav.uniqpath.com/2010/05/semicolons/
x = y
/* TODO: clean this up to make it more readable
* and maybe add some semicolons
*/
+ 4
This is a really nice example of that.
It also is reminiscent of one of my favourite programming jokes:
int x;
int y;
x = 0; /* initialise both x
y = 0; and y to 0 */http://common-lisp.net/project/parenscript/
People are writing Node.js code in it :-)
It reminds me of an old Scheme dialect, implemented in Common Lisp, and was used to implement the Yale Haskell compiler (by Sandra Loosemore[1], et al.); it's just one of those baroque language towers that you're not sure how it works, but somehow works perfectly.
Combine parenscript with CSS-Lite[2] and you enter a weird world of web development in 100% Lisp (not entirely good though; you wont be able to cut-and-paste stuff from SO, but then, thinking for yourself might not be such a bad thing after all :-)
--
[1] Yes, that Loosmore; Ms GNU libc herself, along with being an OG GNU hacker, right from the start and an RMS buddy, she was also an editor of the CL spec.
var bla = function() {
//stuff
//more stuff
//some more
}//no semicolonThe YUI minifier, for example, works perfectly fine without semicolons in the original. Equally, the Google Closure Compiler does also.
If you're using a minifier that just removes new lines and suffers without semicolons, I think you should rethink your minifcation process.
This really shows the cost of this syntactic nicety to the language.
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.
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):
a = b + c (d + e).print()
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:
a = b + c var f = d + e f.print()
should therefore be no less efficient and, on the side of readability, you could even name f to be something worthwhile.
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.
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's none of your business how I choose to code my own projects.
If we're on the same project together, we can discuss it and decide on a style that works for everyone.
When I contribute to an OpenSource project, I adopt whatever style they have defined.
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.