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.
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.
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.
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.