This is a topic that is given a disproportionate amount of attention for what amounts to such a trivial argument. Skip if you get sick or annoyed easily.
This discussion topic is almost — almost — as bad as the tabs vs. spaces debate. And, as arbitrary as that debate is, this is no different. An eternal debate in JS and ECMAScript, forever echoed throughout the halls of blogs everywhere …
To semi-colon, or not to semi-colon — that is the question.
Although the argument has been going back and forth for years, I crossed paths with it just recently, joining a colleague on a new team project. When I got on board, I started the process of establishing a style guide so we'd have uniformly formatted code.
As this process started with me familiarizing myself with the fresh code base, I came upon a VueJS component that the other developer had scaffolded. I noticed he wasn't using semi-colons. Immediately I felt flush, my pulse pounding, blood pressure rising. There was no stopping it, my temper was rising to the surface.
Not really, but I knew what was to come: us arguing our points of view, with valid and justifiable reasoning on both sides. Lacking a universal style guide for the agency I was working with, were we ever going to reach a consensus without wasting too much time?
So I began to research and weigh the pros and cons of those single character termination points.
One argument is that if there are certain cases where a semi-colon is required, then it should be applied in all cases. Why waste brain power on determining when and when not to apply semi-colons?
Borrowed from this post — in general,
\n ends a statement unless:
- The statement has an unclosed parenthesis, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with a
- The line is
++(in which case it will decrement/increment the next token.)
- It is a
else, and there is no
- The next line starts with
., or some other binary operator that can only be found between two tokens in a single expression
The post linked above has answers to each of these issues. I don't know about you, but that seems an awful lot of exceptions if it can all be solved by simply adding
; to the end of your statements.
Semi-Colons: Multi-Line Return Statement
A common argument for using semi-colons is brought up when one writes a multi-line return statement, for whatever reason. Take this as an example:
return keyword, along with
continue as immediate ends to the statement. Thus the interpreter will treat the
7 as a separate line. In order to get this to work, you'd have to add a semi-colon at the end, even if you don't want to.
Semi-Colons: The Parenthesis Argument
This is where you write a line — let's use a variable assignment statement in this case — then immediately succeeding that line, you start another line with a statement that starts with a parenthesis. Without a semi-colon, the JS interpreter will concatenate these two separate statements as one.
Take this code for example.
x = y * z (a + b).print()
This will be evaluated as:
x = y * z(a + b).print();
The solution is weird. The solution is to prepend a semi-colon to explicitly tell the JS interpreter not to concatenate it as one long statement.
No Semi-Colons: Why Bother?
Has anyone ever actually come across a JS interpreter that doesn't handle the absence of semi-colons? If so, name it, anecdotal evidence is not evidence.
Saving characters. For example, minification doesn't require semi-colons to work. Consider the following:
var a=1;var b=2;var c=3; // versus var a=1 var b=2 var c=3
If one considers that the EOL is set to Linux, that's only one character, basically replacing
\n. Tit for tat.
No Semi-Colons: It Looks Better
I don't think there's anything more to say here, this is a matter of personal preference in my opinion.
Some people will argue that a programmer is lazy if they don't add semi-colons. "They're too lazy to type one extra character per statement?" I'm not sure that you can categorically call someone lazy just because of something as trivial as that.
Honestly I should've taken the easy way out, and just asked my reader(s) to comment on their preference instead of wasting time writing this up.