It's a topic that could seem trivial at first sight, but it actually causes some controversy among JavaScript developers. Semicolons, yes or no?
The syntax of JavaScript, just like many other languages, is based on the C programming language. In that language, semicolons are necessary to end a statement (i.e. an instruction.)
But JavaScript interpreters use Automatic Semicolon Insertion, a system that "inserts" semicolons before a line break in some circumstances. It doesn't literally insert it in the code, the interpreter acts as if there were a semicolon where ASI decides to.
For example, In the following code:
const myName = "Nico"
const myLastName = "Zerpa"
console.log(`My full name is ${myName} ${myLastName}`)
The ASI system will add semicolons after "Nico"
on line 1, after "Zerpa"
on line 2, and after the closing parenthesis on line 3.
The exact rules of automatic semicolon insertion can be found on the official JavaScript/ECMAScript specification.
The problem is that omitting semicolons can lead to ambiguous code in some cases where ASI doesn't work as you may expect. Here's an example of this:
function getData() {
return
{
name: "Mel",
age: 49,
favoriteFood: "Pizza"
}
}
const melData = getData()
console.log(`Her name is ${melData.name},
she's ${melData.age}
and she loves ${melData.food}`)
The code above doesn't work because ASI insert semicolons in an unexpected place: after the return
keyword on the second line. On top of that, the JS interpreter gets confused. Due to the added semicolon, it mistakenly thinks the object is a block of code. That triggers a syntax error.
Those kind of problems could be solved if you simply learn when ASI inserts a semicolon. However, coding is almost always a team work. Even if you know the ASI rules by heart, other developers may not, and they could not read the code properly.
For that reason, I decided to use semicolons. It's clearer for everyone, even for the JS interpreter.
If you liked this article, you'll love my JavaScript Newsletter.
Every other Monday, I'll send you easy and actionable steps to level up your JavaScript skills. Check it out: https://nicozerpa.com/newsletter
Top comments (13)
There's a worse issue with omitting semicolons; consider the following code:
This will throw a TypeError that undefined is not a function, because the brackets around the second IEFE are interpreted as a function call. A semicolon between these lines will solve the issue.
mmh.... what is an IEFE?
Immediately executed function expression.
aha, I've only encountered IIFE so far...
(immediately invoked function expression)
I think we mean the same thing
Greeting from the UK.
I do not see this question much these days but it was a common topic of discussion a few years ago. It was a similar "hot topic" to indent using tabs or spaces.
I have tried developing using both styles and (if you know what you are doing) both styles can work. However, I personally find using semicolons more natural and consistent with code I write in other programming languages.
In all the professional grade code I have reviewed over the last four-five years, using semicolons was the preferred style.
I don't add semicolons while programming, rather I wait till I'm done, hit save and let Prettier add them in for me.
I mostly keep the semicolons in the saved files, since I don't want the built code to have any issues with immediately invoked functions in Javascript.
I don't mean to provide a weak answer, but to me, consistency is more important (and this can be achieved by automatic code formatting).
Not a weak answer. Consistency is the most important thing for linting-related issues. Both standards are completely valid. The only thing I would consider is the team's background and preference.
Yes, I know. It's probably the least bad solution in these cases.
Don't forget dynamic method name
5 years ago I also feel semicolon boring. But now I use as sign to myself: I finished the working and thinking this line of code.
"It's a topic that could seem trivial at first sight"
Also on second and third sight.
I used to use them, and now only do so when necessary