There was an eruption of “OMG! Semicolons!” on the internet again. Being someone that, for the most part, follows the npm coding style which does not use semicolons, except at the beginning of lines in certain cases, I continue to be asked the same things over and over again.
It is not possible, nor productive, to try and cover every facet of the semicolon debate. Instead I will cover two things that are important to me and have influenced my decision to not use them as prescribed by Crockford and others. I hope to cover them well enough that even if you disagree with the relative importance of these points you can at least see where I, and others, might be coming from.
I didn’t wake up one day and decide to stop using semicolons. It happened progressively over the course of about a year and a half. During that time I found myself speaking a lot more at meetups and conferences as well as writing more blog posts that included code samples.
Always trying to improve my presentations and articles, I started to take a more critical look at my examples. One thing I found was that cutting down on “completeness,” meaning code that was more correct but was not directly illustrating my point, made the examples much easier to understand. People I’m talking to know how JavaScript works, I don’t need to cover the basics or make all my examples runnable, what they don’t understand is the subject I’m covering and focusing on it will make the presentation work a lot better.
After a while I started experimenting with removing the semicolons. I was hesitant at first, I thought that just the fact that the examples lacked semicolons would be a distraction, but after a few early successes I was convinced that removing unnecessary syntax helped illuminate the meat of the example.
This experience gave me a lot of faith in something isaacs was saying around that time. I’m paraphrasing, but from what I can remember he said something like: “Unnecessary and frequent syntax at the end of every line leads programmers to ignore the ends of all the lines. Typos and errors at the ends of lines become harder to see, removing unnecessary syntax and bringing as much of the required syntax as possible to the beginning of lines, which you can’t ignore because you can’t ignore the beginning of a statement, illuminates errors.” He illustrated some of this in a gist.
I’m very happy using the npm coding style and not just for aesthetic reasons. I find that I have less errors and that I can read code faster and tend to lose my place less often than I did before. This is anecdotal and even though I wrote code with semicolons for years you could argue that I had a hidden aesthetic preference for this style I had not yet realized, but you can’t say that this method is error prone because in all this time I’ve never shipped a bug related to lack of semicolon.
The least productive arguments of the style wars are between those that advocate a style guide they believe reduces errors and those that believe a particular flavor of valid syntax itself is an error. While one can argue that their choices lead to more or less errors, and there can be a variety of differing opinions about what might lead to errors, it is foolish to argue that any valid syntax should be considered an error.
The ECMAScript specifications describe a series of statement termination rules in a section called “Automatic Semicolon Insertion.” This description of language rules as an “error correction” mechanism rather than describing end of line rules in a concise way throughout the specification makes people assume strange things about the implementation of JavaScript and how it’s parsed.
First, let’s state a few irrefutable facts we must all admit.
ASI is a basic part of the language, it’s not an amendment. No sane person would implement it as an afterthought or even as it is outlined in the spec, as “error correction.” Instead, you write a list of rules that end statements, many of which are related to newlines.
The description of semicolon-less JavaScript as “relying on an error correction mechanism” is a shallow characterization and leads to misrepresentation. There is no error in your JavaScript that is being “corrected,” the AST generated from semicolon-less JavaScript is identical to its semicolon riddled counterpart. You can even test this out for yourself using Spidermonkey’s Reflect object.
For as long as we’ve been writing JavaScript we’ve been trying to make the JavaScript that we write run faster and excluding many of the features in the language to achieve this. Characterizing the use of newlines to terminate statements in full observation of the rules of the language does not rely on a feature that will affect performance, but the term “error correction” implies that it does. To someone who is not familiar with how the common parsers are implemented it causes them to imagine a series of swallowed exceptions that are being overcome at runtime.
At the end of the day it doesn’t matter how the spec characterizes the language, remember that this is the same spec that defines the with statement. What matters is that we find the parts of the language that allow us to write code quickly, with less errors, and with better performance. We are always going to have to find our own “good parts” and as implementations change, those parts will change as well. We shouldn’t take our direction solely from language designers or outdated dogmas.