By Mark Brown

Why I Use a JavaScript Style Guide and Why You Should Too

By Mark Brown

This article was peer reviewed by Tim Severien. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Let’s take a look at JavaScript Standard Style by @feross, a JavaScript style guide that’s gaining popularity. It may help you reduce friction on teams and increase programmer happiness.

It’s a set of rules to make JavaScript code more consistent and can prevent boring discussion of the merits of tabs over spaces. It’s one of many styles that you can adopt and sits in the same category as other JavaScript linters such as JSLint, JSHint and ESLint.

If you’re not sure what linters are, or why you’d need one, check out our comparison of JavaScript linting tools

The Importance of Style

If you’ve been coding for a while, you’ll no-doubt have a style that you’ve grown to like. This is what happens when you write certain patterns hundreds or thousands of times, you start to find your way of coding aesthetically pleasing. All of a sudden someone else comes along and starts throwing brackets down in odd places and leaves spaces hanging off the end of lines. There may need to be words. Breathe deeply, your placement of brackets or choice of white-space doesn’t make your programs any more correct, it’s personal preference.

Each programming language has a dominant style, sometimes like in the case of Python an official style guide is presented as the correct way to author programs. Hold on, did you say 4 spaces for indentation?

Coding in the dominant style of a language will help your program fit into the language’s ecosystem. You’ll also find it easier to contribute to open source projects and have others contribute to your own if things are familiar and agreed upon at the outset.

JavaScript doesn’t have an official style guide, perhaps a de-facto standard came out of Douglas Crockford’s The Good Parts. His book presented a way to write reliable JavaScript programs and he highlighted features that we should actively avoid. He released JSLint to support these opinions and the other linters followed suit. Most of the linters are highly configurable and let you choose a style that suits you best and better yet, enforce it on others! JavaScript Standard Style is different. The style that you like best is irrelevant, what’s important is that something, anything is chosen that everyone can understand and work with.

JavaScript Style Guide

Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier.

If you’re writing a program for yourself that no-one else has to contribute to, use the tools and style that make you the happiest. When working on a team you should always aim to reduce friction where possible, be professional and don’t sweat the small stuff.

Take the time to learn the style of the existing code base before introducing your own style.

JavaScript Standard Style

  • 2 spaces – for indentation
  • Single quotes for strings – except to avoid escaping
  • No unused variables – this one catches tons of bugs!
  • No semicolons
  • Never start a line with (, [, or `
  • Space after keywords if (condition) { ... }
  • Space after function name function name (arg) { ... }
  • Always use === instead of == – but obj == null is allowed to check null || undefined.
  • Always handle the Node.js err function parameter
  • Always prefix browser globals with window – except document and navigator are okay
    • Prevents accidental use of poorly-named browser globals like open, length,
      event, and name.

See the complete list of rules

The most controversial rule would undoubtably be No semicolons. It’s been considered best practice for years that semicolons should always be present to avoid bugs, Crockford did a lot to promote this but it also has deep roots in C where the semicolons are strictly required or the program won’t run.

JavaScript Standard Style has changed my mind on this, semicolon free JavaScript is good.

Automatic semi colon insertion is a feature of JavaScript which can reduce noise and simplify programs, I have never run into a bug caused by a lack of semicolons and I don’t believe you will either. See Are Semicolons Necessary in JavaScript? for more on this.

Not everyone agrees, notable forks semistandard and happiness bring back semi-colons with a vengeance. I find these forks a little sad as they seem to miss the entire point of standard.

I disagree with rule X, can you change it?

No. The whole point of standard is to avoid bikeshedding about style. There are lots of debates online about tabs vs. spaces, etc. that will never be resolved. These debates just distract from getting stuff done. At the end of the day you have to ‘just pick something’, and that’s the whole philosophy of standard — its a bunch of sensible ‘just pick something’ opinions. Hopefully, users see the value in that over defending their own opinions.

Personally, I’ve grown to like coding without semicolons, perhaps that’s from time spent writing Ruby, Python and CoffeeScript which require less syntax. Whatever the reason, I find programs clearer when there’s less to look at.


Mark’s Hierarchy of Good Programs

Programmers should value:

  1. Correctness
  2. Readability
  3. Happiness
  4. Efficiency

It turns out that adopting a style guide like standard provides benefits in each of these areas.


To be of any use at all programs must do what you intend and be free of bugs.
Style doesn’t make programs any more correct but a linter can catch errors before they’re released.


As a professional developer, beyond providing a working program, the readability of your code is the most important thing. Far more effort is spent reading and trying to understanding programs than it is writing, so optimize for your future self and other humans that will inherit your code.

A clear predictable style makes code easier to read and understand.

Programmer Happiness

One of the things I love most about this is that it places the focus on the human rather than the machine. The only reason it’s third on the list is that the teams need for readable, functioning code should come before our own happiness, it needn’t come at its expense though.

You want to enjoy life, don’t you? If you get your job done quickly and your job is fun, that’s good isn’t it? That’s the purpose of life, partly. Your life is better.

– Yukihiro Matsumoto

Life is too short to get worked up over differences in opinion over personal preference, set a standard and move on. If a standard style can prevent disagreement and friction among the team you’ll be happier for it.


Last on the list, but not least.

If you have to make trade-offs on any of these points, you should value correct, readable code that makes people happy over fast code.

Computers are fast. If the program is efficient enough then it’s fine. If you notice bad performance then spend time finding the bottleneck and making the code more efficient.

Humans are slow. Making things more efficient for us is far more valuable. The clarity that you gain from adopting a standard style makes your code quicker to understand and contribute to. There’s far less time spent disagreeing too, which is most welcome.

Implementing JavaScript Standard Style

You can adopt the standard without any tools, just read through the rules and take note of the ones which are different. Try it out for a week and see if you like it. If you don’t, use it anyway!

There’s also an npm package for linting your JavaScript code.

npm install standard --global

Running standard will run all JavaScript files in the directory through the linter.

Additionally there are text editor plugins for all of the usual suspects, here’s how to install the linter in Atom.

apm install linter
apm install linter-js-standard

Screen shot of the plugin highlighting errors in Atom

Personally I find automatic linting of programs as you type really distracting. If you feel the same you might prefer to use these linters after you’ve finished your work. The standard command also has a flag for automatically fixing certain style errors which might save you some time.

standard --fix

Adopting JavaScript Standard Style

Should you adopt standard style? Well, that’s entirely up to you.

If you have no style guide in place, then be prepared for a clash of opinions.

If you’ve perfected your ideal set of rules and would like to enforce it throughout a code base, then ESLint may be what you are searching for.

If you would rather not waste time over the boring minutia of syntax then take JavaScript Standard Style for a spin and let us know what you think in the comments below.

  • Saeid Pournejati

    I still don’t understand the semicolon rule. Doesn’t make sense to me.

    • markbrown4

      Did you watch Are Semicolons Necessary in JavaScript? At this point dogma is the reason most people use them. Why not try it on for size for a month and see what happens.

    • The point is really simple, semicolons are automatic injected by the compiler, you can do all the manual work of adding them, but for what? our work as programmer is to automate processes, and this was automated a long time ago.
      The fp is quite popular in js now, the code without semicolons is easier to understand for people that has roots in haskell or ocaml, while the semicolons are more familiar for imperative programmers with roots in C or php.

      • Try getting someone who’s programmed in java to omit semicolons. It’s a habit we can’t kick off 😂

    • Dropping semicolon when writing JS is a breeze for me. It allows me to write quicker as there are less keypress (specially on right arrow to go to end of line in order to insert that semicolon). Moreover, I the code readability is better for me.

    • Martin Dobrev

      Same to me here. And the multiple var declaration as well seems not right…

      • markbrown4

        Multiple var declaration?

      • nnnnnn321

        Using var (or let or const) for every variable makes it easier to move variable declarations around by simply selecting a line and cut/pasting it – you don’t have to worry about adding/removing a comma on the line before, etc. Confining such changes to a single line also helps when doing a diff on two versions of a source file. (But really I don’t see it as a big deal either way. Pick one way and do it consistently.)

      • JoaoReynolds

        I think it depends on your coding style. Multiple var declarations usually means you’re declaring a bunch of mutable vars – I’m not the only one nowadays who tries to avoid mutable vars as much as possible, so I rarely have a need for multiple var declarations anymore (whereas I used to declare all my vars at the top of a function).

    • markbrown4

      Take an recent JavaScript file you’ve worked on, delete all semi-colons at the ends of lines and see what errors occur. While there may be a few cases, there will probably be far fewer than you think.

      • This is not the case, what error do you have in mind for example?
        function test() {
        anyway with semicolons or not, it does example the same, returns undefined. It doesn’t matter if you add 0,1 or n semicolons. The semicolon(end of statement) is intrinsic at the end of the line of the return, Eppur si muove! :)
        In my code, I don’t start lines with ( or [ or `, it is weird and feels hacky, maybe you should consider using const and let to scope your variables in a block {statements} instead of hacky immediately invoked functions

        • markbrown4

          We’re both arguing the same thing :) The IIFE is the only case I was thinking of that may throw errors. I was simply putting the challenge out there to all those arguing that things will fall apart with semi-colons, it won’t and there’s nothing to fear.

    • JoaoReynolds

      No right or wrong IMO as long as a project is consistent. But try a small project without semicolons, and see if you ever go back :)

    • Saeid Pournejati

      Let’s make this argument more confusing. If any of your arguments are correct, why does most IDEs I used (VS, WebStorm and generally JetBrains IDEs, NetBeans and Eclipse both) warn you to add semicolons to the end of you statement?

      • markbrown4

        I don’t use an IDE. “If any of your arguments are correct” Why not test it out and see for yourself? Delete every semi-colon at the end of a line and run it. Watch the video and try to understand what new lines do.

  • Other than no semicolons, I’m following the standard style… I also program in python (been working on learning that, so I’m in python quite a bit recently) what I’m not sure about, is how semicolons make the code more/less readable (depending on your view point)

    • markbrown4

      It’s all of the rules together that make your code more readable, semicolons are only a minor point. For me, they are simply unnecessary work and noise so can be shed. Sam Stephenson does a good job explaining why less syntax clears up code here around 21:50 – It’s related to CoffeeScript but the premise is the same.

  • Giorgio Martini

    No semicolons can be problematic and the compiler not always adds then so it can crete really hard to find bugs…

    • markbrown4

      Not in my experience, please share examples of what you’re referring to. The common cases are the three mentioned in the video above.

      • I had a problem for a missing semicolon once, it’s was for IE7/8 :)

        • markbrown4

          I’d be interested to see where automatic semicolon insertion was implemented differently in IE7/8.

          • Actually, I don’t remember the issue very well, I was writing an ExtJS application, and somewhere in the code, I have missed a semicolon. Maybe it is the ExtJS build process which has failed for IE.

  • Mike McLin

    It is usually very easy for me to adopt new coding styles. I cringed when the at the PHP PSR standards bracing styles, but adopted. I’m surprised how quickly I am (maybe was) willing to completely skip this guide due to the semi-colon rule. Maybe it is because I also code PHP, or maybe because I’ve been taught time and time again that semi-colons are a best practice.

    To call semi-colons noise seems as if there were no merit to them. They help complete an execution. Are they needed, no. But, when present, it seems like you can break the code into executions at a glance without actually having to read (or maybe even understand) the code.

    I tend to usually flow with the industry. I’m seeing more and more projects omitting semi-colons, and maybe one day I’ll follow suit. I think Typescript is in my future, so I wonder once that gets wider adoption, how people will style their TS syntax. That’ll probably be the path I follow.

    • markbrown4

      Yes, it’s funny how certain things like semi-colons create such a strong reaction like it’s against your religion. “They help complete an execution” I understand what you mean but the new line does that perfectly well. Try adding 3 semi-colons at the end of each line and you’ll understand what it feels like to add them unnecessarily.

      • Mike McLin

        My issue is that I’m not sure the greater JavaScript community wants to omit semicolons. The AirBnb JavaScript style guide, which seems to be the most popular with 40k stars on Github uses them. The Angular style guide uses them.

        As I mentioned previously, I didn’t like the PHP PSR coding standards, but they we agreed upon by a committee representing popular PHP projects, so I followed suit. The style guide referenced in this article doesn’t seem to share that luxury. In contrast, it seems to abandon the most popular style guides in respect to this rule. So, whether I prefer semi-colons or not, I’m going to stick with the industry. As it moves, so do I. I think following a style guide is a great goal for any project/team, however, and this one seems like an outstanding choice. It just isn’t the guide for me right now.

  • markbrown4

    The video I linked to argues that there’s less guesswork by omitting them. It’s not about relying on the compiler to fix things for you, it’s about understanding what semi-colons and new lines do in JavaScript. Try it on for size, you may find that semi-colon free JavaScript is perfectly fine.

    • rag

      Personally, I disagree about the guesswork involved. But I also know that it works when you do it right (and it’s not hard). You actually proved my point about the necessity of actively thinking about semicolon insertion. Without semicolons you absolutely must understand what semicolons and new lines do. If you put semicolons in then this is one thing you don’t have to think about. And the less you have to think about the better.

      The important thing is that people are different. Some find the guesswork required without semicolons to be a strain on the brain. Others feel completely opposite. And by that I mean, they feel physically tired earlier by using one method over the other.

      And that’s not only about the semicolons. Personally I used 2 space indentation in my first 10-15 years programming. Now I tend to indent by 4 spaces. It just feels more comfortable to me.

      Therefore, unless you build a compiler that understands only a single coding style specified down to the tiniest detail, you invariably will have multiple standards. Which means, it’s not a standard any more, but just a project specific coding style guide. It’s important to have one, but it’s *not* a standard.

      • markbrown4

        The standard linter alerts you when you write code that will break without semi-colons, no guess work is required. You make it sounds as if omitting semi-colons will make coding really difficult, I think you’ll find this is not the case if you try it for a month.

        There’s nothing wrong with preferring semicolons or 4 spaces, personal preference is fine and old habits die hard. You’re correct that the `standard` linter is not an official standard, it’s simply a style guide for projects that opt-in to it.

        • Camilo Reyes

          One reason I put semicolons is to add correctness and clarity. There is no arguing with the compiler over stupid whitespace. The statement finishes, case closed.

    • Jose Noway

      Some of us work with multiple languages. If you’re switching JavaScript, Java/C#, C/C++ then it’s less mental effort to just use semicolons everywhere. A similar case can be made for ‘ vs “.

      I never understood people trying to save on typing one character. Typing speed is never the bottleneck in coding, except perhaps in the case of extra verbose languages like COBOL and such.

      A strict ‘no semicolon’ rule is just myopic.

      • markbrown4

        A lot of new programming languages don’t require semi-colons, see Python, Ruby, Elixr, Go, Closure etc.. It’s not about saving a keypress on every line. We’re talking about when they’re required at the end of lines in JS and the answer is never.

        • Jose Noway

          How does the size existing codebase and userbase of my group of languages vs yours compare?

          I rest my case.

  • I will never, ever understand why everyone does not use a code formatting tool. A pretty-printer without the printing.

    For me, when my code gets messy, I hit a key combo and, boom, it’s all just the way I like it.

    Someone gives me code with spaces instead of tabs (doesn’t happen because I have enough seniority to avoid that bit of idiocy) and, boom, it’s fixed just the way I like it.

    I consider leaving out semi-colons to be idiotic (having mentally parse the code to determine where a statement ends adds cognitive load I don’t think anyone needs) so I don’t have a setting on my formatter for it, but, if the compiler can do it, then a formatter can, too.

    Oh. You don’t want a formatter putting in and taking out semi-colons? You think it might cause some problems? Me too.

    The idea of trying to make every person in a team look at the same thing is as ridiculous as trying to make them all use the same editor (I’m looking at you .NET).

    I laugh every time I read about people insisting on using a linter. Have you ever heard of an abstraction layer? Just call it a formatter and you get the idea.

    • markbrown4

      Linting is far more powerful than formatting, it understands the code so can tell you about unused variables for example. If you want your code to appear “just the way you like it” it doesn’t sound like standard is a good fit.

      I honestly don’t see any truth in the argument that leaving off semi-colons adds cognitive load, the only way to see if it’s true or not is to try coding without and see. Semis( No semis( no big deal really.

      • Why would a linter understand the code better than a formatter? Maybe a dumb formatter but, it’s the same thing except that one reports errors and one fixes them.

        As for semi-colons, I’m an old programmer. I’ve done *everything*. Even in the era of functional code, I notice it’s more effort to look for the end of the dotted function list.

        It’s obvious that putting in an explicit end of statement marker, aka, semi-colon, is more easily visible than a newline that could be in the middle of a statement.

        • Andrew Finnell

          I’ve never known a formatter to fix any errors, ever. Perhaps you could share some pretty-printers that are able to auto-magically fix coding errors. That’d be something to marvel at. Even linters don’t automatically fix everything, even if they automatically fix anything at all.

          Formatters deal with subjective issues (style’ing).
          Linters deal with statistical probabilities of your code causing a bug, now, or in the future. Not so subjective.

          Lately, linters have been created and setup to ‘complain’ about styling. That’s where things went wrong.

          Formatters have no idea if you’re using a variable without having initialized it. All it knows is that the declaration should all be on one line, or multiple lines depending on the configuration. There isn’t any static analysis involved.

          Linters contain static code analysis, and in some really good one’s, ‘run’ a mock version of the code to detect things like: dead code, use of uninitialized variables, possible divide by 0’s, use of a possible missing property (ala hasOwnProperty), etc. Formatters don’t possess any of this logic. At all.

      • I didn’t not say it’s a big deal. I say that it’s a deal. Your examples are tiny and artificial. Code is not always formatted well. Whitespace can mean a lot of things, including nothing. Semicolons always are a sign that a statement is ended. I claim that “mean a lot of things” vs “always are” is the definition of increased cognitive load in this context.

        I note that this conversation started with formatting standards, not the inappropriate use of ‘switch’ statements or the specificity of your equality comparisons. I accept the possibility that a programmer might want a smart advisor to warn against those things.

        In another comment on this thread, the person made clear that he wanted to author of a program to be perfectly undetectable and that personal style is intrinsically bad. I think this is an awful, authoritarian view and would seek a new job as soon as that guy gained authority where I work.

        It seems to me that there is a trend to desire uniformity that, for most of my long career as a programmer, was anathema to the hacker ethos. I do not suggest any stupid view that bad code should be allowed. Testing is good. Failing to declare a variable should be detected and ridiculed.

        However, the point that started this conversation, that programmers should embrace The Overlords when they tell us how to set the indentation on our code editors (perhaps they have figured out that productivity is harmed because I am using the wrong typeface, or background color in my terminal) or that my sincere belief that semi-colons are essential is unacceptable because “you must conform for the good of the collective!”

        Well… I don’t agree.

    • Andrew Finnell

      And all your code is stored on a shared drive, zipped on a weekly basis? Going from curly bracket on next_line to curly brack on same_line creates a situation where the entire file will diff as being different. At any professional shop that creates professional software one engineer should be able to check out any file in the system and NOT tell who wrote it. If they can, there’s a problem. One that will be evident enough when that person leaves the company.

      And conforming to a single editor provides a tremendous amount of business value. Commercial plugins can be the same across the board. A new graduate comes aboard and they don’t have to talk to half a dozen engineers to figure out how to build the projects (because each engineer did it ‘their own way’.)

      There is nothing worse then coming into a company as a consultant, trying to figure out IF theres a build server, IF there’s a version control system, and then attempting to rebuild the ‘common knowledge’ collected through out the years on why there’s a Makefile which launches Ant, that then goes back into Make, then bash, then checks out some code, changes it, checks it back in, downloads a zip, unzips it, runs Maven, then packages everything with tar. Yea, standards are a good thing. It prevents silliness.

      • If you use a formatter on the way into your shared drive, then diff’ing will work just fine. However, if you are using diff to figure out the state of your code, I don’t believe that style is going to save you.

        Noting that I’ve been a software professional since 1978, I disagree, and always have, with the idea that programmers should be invisible, matching some authoritarian ideal of sameness. Not only is the idea that, if you are sophisticated and sensitive enough to know the programmers and the code, anyone could ever write code that does not reflect their identity is, I think, silly.

        But, I guess we have a difference, I think that coding is an art form. The perspective of the coder, the techniques that he understands best, the style of his variable names, his choices about defaults and nesting of loops, or map and filter, all are unique. It is a tremendously personal expression.

        I understand that corporate types would prefer that we all get much closer to anonymous drill punch operators. Pound out the code as quickly and uniformly as possible because we want to be able to replace you effortlessly. I don’t believe it’s either a good idea or possible.

        You tip your hand, though, in your last sentence. People who don’t “Follow the Standards, Soldier!” are going to produce “silliness”.

        They also won’t produce “innovation”. Or “beautiful code”.

  • nnnnnn321

    I don’t care whether people use semicolons or not. I do use them, so obviously I’m used to seeing semicolons after every statement in my own code, but I have no trouble at all reading other people’s code without them.

    And though I use them myself I completely disagree that leaving them out involves any guessing about where statements end – the compiler doesn’t guess, it follows a strict set of predicable rules. There is no element of chance involved.

    And the human writing or reading the code doesn’t need to guess either because with or without semicolons I always finish statements with a new line – don’t you? Some statements go across multiple lines, of course, for example when a bunch of function calls are chained together it can be easier to read if each one is on a new line, but in those cases I always indent the second and subsequent lines within the statement and each function in the chain will have a leading . so it is still immediately obvious where the whole statement ends. I imagine you do something similar.

    I guess my point is you can use them or not according to your personal preference, or according to the agreed standard at your workplace, but the idea that not using them makes the code less complete is nonsense, and the idea that not using them makes the code harder to understand may be true for some people but is certainly not true for everyone and either way is generally way overstated.

  • Try commenting out `bar` when you’re debugging and you’ll find you need to modify the declarations, whereas the multiple-var declaration pattern allows for a single line to be commented.

    • Kenneth Davila

      multiple var declarations is not a pattern, it’s just syntax preference.

  • I could go either way on the semicolons, but this one seems out of step with the JS code I see:
    Space after function name function name (arg) { … }
    I don’t recall ever seeing code that does that in any programming language.

    • markbrown4

      Yeah, that one was new to me as well. I’m not sure of the reason behind it but can take a guess. It does create consistency with some other statements like `if (condition)`. It also makes it more clear when the space is omitted that you are calling the function `example()`. Most people who adopt standard need to make a small compromises on a couple of rules that they didn’t previously follow.

      • Stephen Cunliffe

        I’ve never understood any reasoning behind this. For every language I’ve ever used that uses parens around if/do/while/for cond, and method calls I’ve never added spaces and see no reason to waste space doing so.

        function foo(param){

  • JoaoReynolds

    With all the no semi-colon haters out there, I wonder how many have tried it on anything more than a few lines of code? I used to think the same thing. Things like, “what if it fails?” or “Then I’d have to think harder to recognize when lines end”. But on one project I decided, “what the heck, I’ll try it” – it didn’t take long (I mean, more than an hour) for my brain to go from wanting semicolons, to despising them polluting my code. I’ll never go back.

    I’m not going to tell any of you one is better than the other – all I can say is once I stopped using them, I really liked it.

    • If you ask me, no semicolons makes JS look more modern. And, why should I, as a programmer, do the work a computer can do for me? There is no reason at all to do the work of adding semicolons, other than personal preference, which is up to each individual.


  • jmeyer43

    Since the only thing JS auto-semicolon insertion does is fix syntax errors, this is a complete nonstarter for anything that needs to be maintained, or anything where any developer is being paid. This “standard” describes write-once read-never code. Checking in Javascript that needs to be fixed by semicolon insertion should be grounds for termination, and the rule about when it’s OK to put a semicolon at the beginning of a line and what characters can’t go at the beginning of a line is proof of why it’s impossible for professionally written code to be affected by semicolon insertion, because there does not exist a developer who is both worth a salary more than $0.01 per 100 years and willing to write code with known syntax errors.

    • markbrown4

      You’re welcome to use semi-colons. You should be aware that in nearly 100% of cases they are completely redundant though. If you watch the suggested video and try coding without them for a month I will be interested to hear if you still feel the same way. The only people who react strongly to the thought of omitting them are those who have never tried doing any different.

      • Andrew Finnell

        Sadly, this has nothing to do with whether someone has tried using them or not. It has to do with whether you’ve ever written a Lexer and Parser and understand what actually happens with with a Lexer and Parser. Take UglifyJS for example. While it implements its own tokenizer and doesn’t use a Parser Generator, it is obvious that it creates MORE work for the parser when a semicolon is missing. Check it out yourself: line 758. If the terminating token isn’t there it has to go through a list of possible other reasons the statement has been terminated. If it can’t find a valid reason it throws.

        The semicolon, while not really pleasant to look at constantly, is really there to make the Predicates for the Parser generator easier. Semicolons weren’t added due to some over zealous idea of what’s right or wrong. It was added because the people creating Tokenizers and Parsers pull their hair out having to forward look to determine what may or may not be a Statement. The semicolon makes all this trivial. page 176 goes into great detail on the EXCEPTIONS to automatic semicolon insertion and should provide enough objective evidence on why putting explicit semicolons is NOT a style choice.

      • As long as this

        var obj={a:’a’, b:’b’};
        var a = obj

        produces an error, semi-colons are mandatory and any suggestion to the contrary is childish perversity.

        • markbrown4

          Call me a childish pervert, but this is a better way to write that code:

          var a=[{a:’a’, b:’b’}]

          • Obviously. But that would sort of defeat the point of the example, wouldn’t it?

  • gotofritz

    You made a mistake in bringing up semicolons – as you can see, people in the comments are talking about nothing else! I must admit I stopped reading when I reached “JavaScript Standard Style has changed my mind on this, semicolon free JavaScript is good.” Semicolons are part of the language, end of.

    • markbrown4

      I count nine people that like semi-colons. Personal preference is fine but there’s zero compelling reasons to.

      • gotofritz

        That’s just your personal preference. And the people who feel the need to write comments are not representative.

  • Kenneth Davila

    All these dudes, that leave semi-colons out and fight for it think they’re hip or something…. LOL… Hipsters have invaded the programming realm….

  • I use jsfmt integrated with my code editor bbedit. It does a nice job of cleaning up and indenting JS code. I don’t have to worry about keeping it nice looking while I am typing. A touch of a command key and, boom!, it’s properly formatted.

  • Sebastian Simon

    I’m not going to adopt the “No lines starting with [, ( or `” rule. Things like [“keydown”, “keyup”].forEach(ev => addEventListener(ev, …)) or the idiomatic IIFE (function(){}()) are far too useful.

    • markbrown4

      Yeah, I’ve said the IIFE is the only case that requires a slight modification. If that’s all that’s preventing you from adopting standard it’s no problem really.


      One of the benefits of the semicolon rule is to force you to break down lengthy lines onto separate lines.

      var keys = [“keydown”, “keyup”]

      • Sebastian Simon

        Then again, the “fixed” IIFE uses a semi-colon… there’s also “!function(){}()” or “+function(){}()”.

        • markbrown4

          standard is about far more than these edge cases. The challenge is simple, try it on for size and see for yourself. You’ll most likely find that it works just fine.

          • If humanity avoiding doing things because of the exceptions, we’d still be living in caves.

  • Jacob Ward

    ASI is not “a feature of JavaScript”. According to the ECMAScript spec, and Brendan Eich (creator of JavaScript), it is an “error correction mechanism”. Thus, not using semi-colons is – by definition – wrong.

    Whether you choose to use them or not is, of course, a matter of personal preference. Personally, I prefer to write error-free code.

  • Phil

    Everyone knows a standard style is needed. The issue is- why do people need to accept a Standard-Nazi who will force everyone to follow the style by trolling those who deviate.

    • markbrown4

      And the “troll” here is the linter? it can be part of the build or checks that run when a PR is opened, so no-one needs to troll at all. The machine alerts people when there’s style errors and they can fix them in their own time.

      • Phil

        Depending on the team, it may need to be a human too. People can change .eslint file or just ignore them. Nothing malicious, it just that things like that happen with people, especially newbies or those who rush production over quality.

Get the latest in JavaScript, once a week, for free.