🤯 50% Off! 700+ courses, assessments, and books

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

    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.