An Open Letter to JavaScript Leaders Regarding Semicolons

I think that issacs is missing the part where <i>other people</i> try to read his code. We put semicolons at the end of each statement, even though it's shorter to leave them out, because it's how JavaScript is written, and how others are comfortable reading it. We spell English correctly, even though it's full of meddlesome "ou"s and "gh"s, because that's the way English is spelled. In fact, issacs' proposed semicolon-less, comma-first style reminds me of Mark Twain's "Plan for the Improvement of English Spelling":<p><pre><code> For example, in Year 1 that useless letter c would be dropped to be replased either by k or s, and likewise x would no longer be part of the alphabet. The only kase in which c would be retained would be the ch formation, which will be dealt with later. Year 2 might reform w spelling, so that which and one would take the same konsonant, wile Year 3 might well abolish y replasing it with i and Iear 4 might fiks the g/j anomali wonse and for all. Jenerally, then, the improvement would kontinue iear bai iear with Iear 5 doing awai with useless double konsonants, and Iears 6-12 or so modifaiing vowlz and the rimeining voist and unvoist konsonants. Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi ridandant letez c, y and x — bai now jast a memori in the maindz ov ould doderez — tu riplais ch, sh, and th rispektivli. Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.</code></pre>

For me the reason to always use semicolons is the same reason I always use ===. There are just too many rules to remember and I've got more important things to keep in my mind.<p>It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.<p>I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.

Here's what Crockford has to say on the subject:<p>"One of the mistakes in the language is semicolon insertion. This is a technique for making semicolons optional as statement terminators. It is reasonable for IDEs and shell programs to do semicolon insertion. It is not reasonable for the language definition to require compilers to do it. Use semicolons."<p><a href="http://javascript.crockford.com/survey.html" rel="nofollow">http://javascript.crockford.com/survey.html</a><p>I'm inclined to agree. You already have to deal with enough complexity while you're programming, why add more? It's easier to follow the rule 'always use semicolons' than to try to selectively use them.

Since my <a href="http://eloquentjavascript.net" rel="nofollow">http://eloquentjavascript.net</a> recommends always terminating statements with semicolons, I guess I'm being directly addressed by this.<p>The suggestion that 'I don't understand semicolon insertion' doesn't really hit the mark. I wrote a JavaScript implementation.<p>Yet still I recommend everyone to use explicit semicolons. Going over the proposed style on this page, it all sounds pretty good, and semicolon insertion is starting to look okay. Until you realize that he wants you to start every line that starts with [(+/-,.* with a semicolon. This <i>is</i> needed to prevent semicolon insertion from failing you.<p>I'm sure one can get used to such a style, but it is completely 'out there', radically disconnected from JavaScript's C parentage, and, though that's a question of taste, ugly and irregular. This solution is worse than the problem, I think.

We programmers have a tendency to focus our arguments about code almost entirely from the perspective of code creation rather than maintenance, and I think that's in part what this article does.<p>An experienced coder who knows how Javascript works is unlikely to create problematic code even without semicolons, but it's fairly easy to imagine how errors could be introduced as a large, complex program is maintained by multiple developers, some of them potentially less experienced than the author. Like conditional braces in C, Javascript's semicolons are an optional syntax that can be used to make code more foolproof, and therefore more maintainable - though perhaps at the expense of some programmers' aesthetic preferences.<p>Really, though, I find most arguments about syntax aesthetics annoying, especially when people get their passions so inflamed over presentation rather than meaning that they have to risk "insulting" people. The stakes are so small. And if what you believe is so important, wouldn't it be better to convince people rather than intentionally alienate them?<p>People usually think there's a 1 to 1 correlation between "I like this" and "this is objectively good" and then spend a lot of time trying to logically justify their tastes. But taste doesn't really work that way - otherwise how else can you explain the popularity of Britney Spears?<p>I have my own tastes about how to write code in the languages I use, but I recognize that those preferences are generally just that - matters of taste - and tend not to try forcing them on others.

The author doesn’t seem to work in a team where the code is going to be touched by multiple people, all with varying levels of competence. It’s easy to explain to your colleagues that JS should have semi-colons added or weirdness can happen. It’s less easy to say ”Here’s the ECMAScript spec, go read it“ when they’ve got ruby and HTML and CSS and SQL to write and simply don’t have the time to thoroughly master each and every part of the stack.

While there may be nothing technically wrong with Isaac's style, and it may in fact be slightly "better" in some way, it's clearly not how the language was intended to be written or how the <i>vast</i> majority of people write it.<p>I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend <i>some</i> lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.<p>I couldn't care less what your pants policy is in your own home, as long as I never come over. But when you invite me over (i.e. open source a project) and you have a ridiculous pants policy don't expect me to come back.

I do not like inconsistency. I never leave out curly braces. I never omit semi-colons. There is no reason to do so.<p>I dislike working on code written by people who feel the need to omit these symbols. I would prefer if JavaScript would, like PHP or C, <i>require</i> semicolons at the end of every statement.

And so once again, Alan Perlis' famous quip is proved right: syntactic sugar causes cancer of the semicolon.<p>Seriously -- look at the complexity of these rules, and then tell me that Lisp's parentheses are worse.

JSLINT will catch basically all of these problems for you automatically, with it you don't have to worry about improperly parsed code, semi-colon insertion, ==, for in, the stupid constructors like new Function and new Object, implied globals, or most of the crap in the language.<p>There are still some deep problems with JavaScript that no tool, not even JSLINT can fix, like the fact that the language uses + for both concatenation and addition, there is no namespaces, there is no way to create immutable objects, etc.<p>I recommend you use a good IDE (like Eclipse) and hook it up with JSLINT so that you can ensure that you don't ever accidentally create global variables or create statements that the parser doesn't understand.<p><a href="http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse-plugin.html" rel="nofollow">http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...</a>

This blog post reminds me of individuals who will only drink high quality naturally purified twice-filtered water from the mountains of Switzerland.

I honestly never thought that much about the use of semicolons vs not.<p>I'm not a hardcore JS programmer, I know enough to get paid for it, and I'm the best JS programmer of my current employer. But I'm far from a jedi master.<p>Isn't this just a matter of personal preference? A semi-colon is interchangable with \n as long as you use it following the same rules. Which I do because I treat it as a visual marker for the end of a statement.<p>The counter argument is why use it if the system already recognizes the \n in place there, for which I say to make it easier for other JS programmers to recognize and parse since the \n is used in other places where it isn't the end of a line.<p>I guess I don't really see this as a compelling argument being made here, or I've misunderstood what is being argued.

Use semicolons, always. Then you don't need to learn all the rules and caveats and ambiguity.

I think the reasons a lot of people use semicolons is that it's just easier. Also if you come from a language that enforces them, it's natural just to use them. That's why I use them anyway.

Hopelessly pedantic … use them (or don't), but either way don't waste too much time on this subject. Focus on things that matter more.