In the (fairly old) programming language C, it’s clear; a semicolon has to follow every statement. It’s a statement terminator. An odd choice in itself, seeing as in our own language the semicolon is precisely not that. In programming languages, though, it provides structure.
In modern programming languages, such as Go and Swift, the semicolon is optional, however. It doesn’t have to be there, and in these languages it’s often seen as a nuisance too.
JavaScript dates from 1995 and falls somewhere in between. It’s optional, but unlike in Swift, for example, not everyone sees it as a nuisance. There are clearly two camps; those who think it should always be used, and those who think it should never be used. And in between sits a small camp that leaves it to the tooling. More on that later.
AUTOMATIC SEMICOLON INSERTION
Before we can understand the camps, there’s one more thing we need to know about; ASI. Automatic Semicolon Insertion is the automatic addition of semicolons in places where the JavaScript language expects them but the programmer hasn’t added them explicitly. There are clear rules for this, and they’re well documented. For now, it’s enough to know that it happens. Because it happens automatically, it’s sometimes unexpected, and it sometimes causes problems. And where there are problems, there are solutions. And where there are solutions, there are opinions.
CAMP ALWAYS A SEMICOLON
This camp believes you should always type them in explicitly. If ASI can sometimes cause problems, it’s better to stay ahead of those problems and always use the semicolon. It’s simpler to always use them than to know and understand when ASI gets it wrong.
CAMP NEVER A SEMICOLON
This camp holds a somewhat more nuanced view. They assume ASI is always present and does its job well. The situations where ASI can cause problems are, in their view, situations that should be avoided anyway, because they’re ‘bad coding practice’. They believe the language reads much better without semicolons and has a more modern feel.
CAMP I DON’T BURN MY FINGERS
You can also choose a middle way. You don’t type them in explicitly in your code, but the editor (combined with a few extensions) adds them for you. So they do end up in your final code, and technically that puts you in camp ALWAYS after all.
ESLINT DOESN’T HAVE AN ANSWER EITHER
So what’s the general trend, really? You can usually find it in the settings of linters, code sniffers and fixers. ESLint has a clear rule, ‘semi’, which takes two values; ‘always’ and ‘never’. These clearly match the two camps. For ESLint, ‘always’ is the default value for ‘semi’. And with that, it lines up with camp ALWAYS. However, the ‘semi’ rule isn’t included in the ‘eslint:recommended’ rule set. A default installation extends this rule set. And so ESLint doesn’t pick a camp after all.
WHAT IS THE STANDARD NOW?
The ‘JavaScript Standard Style’ (standardjs) is a guide, linter and fixer. It’s used by many companies and communities and seems to be becoming the de facto standard for JavaScript. They clearly choose camp NEVER. The situations where ASI can cause difficulties should never come up at all, because they’re evidence of poor programming style.
So it looks as though camp NEVER is slowly gaining ground.
But as is always the case with camps, there will always be one that will never fully commit to NEVER, with a wink, or is that a wink without a semicolon?
More info:
https://tc39.es/ecma262/#sec-rules-of-automatic-semicolon-insertion
https://eslint.org/docs/latest/rules/semi