I think this style ("npm style") is trying too hard to be clever without much benefit. Classic JavaScript style (see: Crockford) has done just fine and is familiar to everyone who knows C-style syntax. No reason to change it now.<p>I'd rather consistently have semicolons at the ends of lines than crap like this:<p><pre><code> ;(x || y).doSomething()
;[a, b, c].forEach(doSomething)
</code></pre>
It's easier to always include the semicolons at the end of statements rather than try to figure out the edge cases where missing a semicolon would change the behavior.<p>I'm also not a fan of the "comma-first" style, especially for var declarations...<p><pre><code> var foo
, bar
, baz
;
</code></pre>
I prefer:<p><pre><code> var foo;
var bar;
var baz;
</code></pre>
It's fewer lines, consistent, symmetrical, and it's impossible to introduce errors through copy/paste or reordering.
I hate semicolons too, but I wouldn't recommend removing them in your javascript. Douglas Crockford says to use semicolons, so use semicolons. JS lint is a useful tool and its worth having your code conform to it.<p>If you really hate the syntax quirks of javascript like me, a better solution is to just preprocess it. CoffeeScript has made me really enjoy writing frontend ui code again. <a href="http://jashkenas.github.com/coffee-script/" rel="nofollow">http://jashkenas.github.com/coffee-script/</a>
Well, there are a few narrow examples where omitting semicolons will lead to incorrect code. If you're a superhuman javascript whiz who never makes mistakes, then sure, leave out the semicolons. But for the rest of us mortals, it would be nice if you left them in.
The one place where this really bites me is return statements. For example:<p><pre><code> function x() {
return
2+3;
}
alert(x());
</code></pre>
Every now and then I'll reformat a line by breaking it in two and it takes me 10 minutes to figure out why my code is not working.
If you prefer not to use semi-colons in JavaScript but need to add them for other’s sake, you could try programming in CoffeeScript (<a href="http://jashkenas.github.com/coffee-script/" rel="nofollow">http://jashkenas.github.com/coffee-script/</a>), which is a language meant to be a bunch of small improvements to JavaScript that compiles into JavaScript. It doesn’t require semi-colons. You can show others just the compiled JavaScript, and they need never know you are using something else.<p>Edit: ninja’d by railsjedi: <a href="http://news.ycombinator.com/item?id=1762677" rel="nofollow">http://news.ycombinator.com/item?id=1762677</a>
I realize semicolons aren't required for javascript, but I put them in anyways merely because I do so much coding in other languages where semicolons <i>are</i> required that it's silly to try and modify my habits just because it's not a requirement to put in.<p>Just because you don't wear pants at home doesn't mean you're not going to feel silly showing up at work without them.
There are numerous cases where lack of semicolons create ambiguous code which introduces bugs.<p>Here are some: <a href="http://gist.github.com/612814" rel="nofollow">http://gist.github.com/612814</a><p>Edit: Er, tried to paste code in-line but formatting got messed up.
On the "if we were to design a programming language" level,
it seems that a feature like ASI (Automatic Semicolon Insertion) is not only useless but even harmful. Every programmer is required to learn the rules of the mechanism in order to understand others' code. Furthermore, it needlessly increases the amount of possible programming styles, which, in my opinion, is a bad thing.<p>C programmers have always used semicolons and never wasted a second thinking whether they should.
I always use semicolons in js because I usually compress the code down by removing superflous whitespace -- which would make this style of code not function at all.
I'm fine with coding conventions that aren't anal. Do I wear pants to my friends' houses? Yes. However, I won't go over there many times if the rule is that I have to wear black khakis I bought at Wal mart and have exactly 5 pockets.<p>Same for coding conventions. Want me to use camel casing for global variables even though I think it's hideous? Fine. Want me to put closing parenthesis on a newline by themselves on a multiline function call and I put it at the end of the last line? Find something better to do with your time.<p>Unfortunately, I don't know enough JavaScript to know where this falls.
One related issue is how should one mark up code that <i>is</i> intended to flow over multiple lines? Consider doing a long chain like:<p>MyObj.item.childItem.getAll()[0].properties... // etc.<p>It's common to want to split this over several lines. I am in favour of placing the the period at the end of the line to indicate that the expression continues. Other people prefer the dot to start the next line instead. I don't like the latter since the first line then looks like a mistakenly omitted semi-colon.
Um, ok, the ASI quiz is clearly lame: out of 41 I missed two and wasted one, and I know <i>no Javascript whatsoever</i>. So I'm not sure what that was supposed to prove.
The problem is that there is an actual drawback to making semicolons optional: adding a newline between tokens can change the meaning of the code!<p>This "feature" is really just a bad idea. I would hope that it gets thrown out in future versions of the standard (is there one?), and use semicolons in the meantime.
I am certain there are words of wisdom in The Pragmatic Programmer book that correlate to this post. I'll update my comment if I find it, but I'm sure someone here will remember it before me.
I always use semicolons, because I also code in several other languages, that require them. But I have no problem, if someone leaves them out. This is how JavaScript was designed.
I know this is about semi-colons.. but it's more the comma at first that I found weird.<p>Example of what I mean:<p>- "Do a, b, c, ..." vs
- "Do a ,b ,c ,..."
Considering semicolons are needed or optional in most languages why not just get in the habit of typing them? Sometimes that means I slip them in my Python code, but everything still works. Just makes more time for thinking about what the code is actually doing.