JavaScript and the Semicolon

5 years ago
to ;
or not to ;

I still remember when I moved from Visual Basic (a short-lived experience) to C# for the very first time. I loved the way it was structured and it felt more readable, though retrospectively it was less about the lack of semicolons and more about the halving of Pascal-cased words and the cool new curly braces that seemed to visually break up the structure.

Visual Basic

Module Test
    Sub Main()
        System.Console.WriteLine("I am Visual Basic")
    End Sub
End Module

C#

static class Test
{
  public static void Main()
  {
    System.Console.WriteLine("I am C#");
  }
}

When I moved to JavaScript, the language felt even more terse than C# since their was even less Pascal-casing and starting curly braces were on the same line of the start of the code block.

JavaScript

console.log('I am JavaScript')

class test {
  static main() {
    console.log('I am JavaScript with class ;)')
  }
}

Visually comparing Visual Basic to C# is kind of like comparing JavaScript to CoffeeScript or HTML to Jade (now pug), but you can make your code even more concise. Given the latest JavaScript standards, you can replace functions with arrow functions (hopefully you understand the difference), using concise bodies, and use destructuring over Array methods or Object.assign.

Needless to say you'll find plenty of discussions on this and it has definitely shown all the sorry signs of religious war (read this or this), on par with the "tabs vs. spaces" nonsense.

At the end of the day, what matters?

  1. Will my code break?
  2. Will my code become less readable?

The former is unquestionably critical and the latter still highly important, though it can be more subjective. In my case I have experimented for several months without semicolons and found omitting them did not cause either of these problems. If you'd like to walk on the wild side...keep reading.


JavaScript Semicolon Rules (Simplified)

Where I use Semicolons

  • for loops
    • this one should be pretty obvious

The remaining likely don't apply and/or will be flagged by a decent linter...

  • var with IIFE on the next line
    • not likely you'd do this or be using IIFEs anymore in the first place
  • multiple line return (unless using Template literals)
    • likely just a mistake
  • not using a bundler or minifier (See references for more details)
    • Sraight-up node applications without minification or bundling, may be an exception, though I have several and had no problems.

The Team Rulez!

While I have discarded semicolons as a personal preferences, it is more important to have consistency across the team and I have worked on many teams that still use semicolons or have large legacy code bases that they don't want to risk refactoring.

Either way, If you want to make your life easier, just use a linter based set of rules. Standard is the one I use, and though it has a bit of a smug name and is opinionated, using it requires less thinking on my part. Plus, if you really love your semicolons, you can always use semi-standard.

standard semi-standard


Hint: standard with ES

If you are using standard and WebPack, plus trying to use the latest ES standards, I highly recommend installing babel-eslint and updating your package.json

npm install babel-eslint --save-dev
  "standard": {
    "parser": "babel-eslint"
  }

Silicon Valley "They tried to convice me you were some sort of formatting Nazi..."


References

An Open Letter To JavaScript Leaders Regarding Semicolons
JavaScript Semicolon Insertion - Everything you need to know
Are Semicolons Necessary

Discuss on Twitter