Update July 15th 2013: Due to commenters demand, we have re-published this research as a Git repository anybody can contribute to: github.com/Seravo/js-winning-style. This article has become our most popular article with over 10 000 unique readers, so this issue is clearly something the JavaScript community should get done.

Update August 16th 2013: A translation in Russian has been published at Habrahabr.ru and it has over 12 000 views. A Chinese translation has been published at liruobing.cn and guochengyao.cn. The updated version at GitHub has been written by 4 new contributors. Thanks everybody!

Update November 11th 2013 There is now a project called Popular coding conventions on GitHub which analyzes (among others) recent JavaScript code and how popular different coding styles are. We are pleased to note that the style recommendations presented in our article match the results found in the GitHub analysis.

If your code is easy to read, there will be fewer bugs, any remaining bugs will be easier to debug and new coders will have a lower barrier to participate in your project. Everybody agrees that investing a bit of time following an agreed-upon coding style is worth all the benefits it yields. Unlike Python and some other languages, JavaScript does not have an authoritative style guide. Instead there are several popular ones:

Then of course, there are also the default settings chosen in JavaScript syntax checkers JSLint and JSHint. The question is, what is the ultimate JavaScript style to rule them all? Let’s make a consensus based on these six style guides.

Indentation

Two spaces, not longer and no tabs: Google, npm, Node.js, Idiomatic

Tabs: jQuery

Four spaces: Crockford

Spaces between arguments and expressions

Use sparingly like below: Google, npm, Node.js

project.MyClass = function(arg1, arg2) {

Use generous white space like below: Idiomatic, jQuery

for ( i = 0; i < length; i++ ) {

No expressed opinion: Crockford

Many guides remind not to have any trailing spaces!

Line length

Max 80 characters: Google, npm, Node.js, Crockford

When wrapping, other indentation than two spaces is allowed to for example align function arguments to the position where the first function argument was. Another option is to use four spaces instead of two when word wrapping long lines.

No expressed opinion: jQuery, Idiomatic

Semicolons

Always use semicolons and don’t rely in implicit insertion: Google, Node.js, Crockford

Don’t use except on some situations: npm

No expressed opinion: jQuery, Idiomatic

Comments

JSDoc conventions: Google, Idiomatic

In the Idiomatic Style Guide also simpler comments are allowed, but JSDoc encouraged.

No expressed opinion: npm, Node.js, jQuery, Crockford

Quotes

Prefer ' over " : Google, Node.js

Double quotes: jQuery

No expressed opinion: npm, Idiomatic, Crockford

Variable declarations

One per line and no commas: Node.js

var foo = ''; var bar = '';

Multiple in one go with line ending commas like below: Idiomatic, jQuery

var foo = '', bar = '', quux;

Start with comma: npm

var foo = '' ,bar = '' ,quux;

No expressed opinion: Google, Crockford

Braces

Use opening brace on the same line: Google, npm, Node, Idiomatic, jQuery, Crockford

function thisIsBlock() {

These also imply that braces should be used in all cases.

The npm style guide states that braces should only be used if a block needs to wrap to the next line.

Globals

Don’t use globals: Google, Crockford

Google says: “Global name conflicts are difficult to debug, and can cause intractable problems when two projects try to integrate. In order to make it possible to share common JavaScript code, we’ve adopted conventions to prevent collisions.”

Crockford states that implied global variables should never be used.

No expressed opinion: Idiomatic, jQuery, npm, Node

Naming

Variables

Start first word lowercase and after that all words start with uppercase letter (Camel case): Google, npm, Node, Idiomatic

var foo = ''; var fooName = '';

Constants

Use uppercase: Google, npm, Node

var CONS = 'VALUE'; var CONSTANT_NAME = 'VALUE';

No expressed opinion: jQuery, Idiomatic, Crockford

Functions

Start first word lowercase and after that all words start with uppercase letter (Camel case): Google, npm, Idiomatic, Node

Prefer longer, descriptive function names.

function veryLongOperationName()

function short()

Use vocabulary like is, set, get:

function isReady()

function setName()

function getName()

No expressed opinion: jQuery, Crockford

Arrays

Use plural forms: Idiomatic

var documents = [];

No expressed opinion: Google, jQuery, npm, Node, Crockford

Objects and classes

Use Pascal case (every word’s first letter is capitalized): Google, npm, Node

var ThisIsObject = new Date();

No expressed opinion: jQuery, Idiomatic, Crockford

Other

Use all-lower-hyphen-css-case for multi-word filenames and config keys: npm

Suggested .jshintrc file

JSHint (http://www.jshint.com/) is a JavaScript syntax and style checker you can use to alert about code style issues. It integrates well into to many commonly used editors and is a nice way to enforce a common style. See JS Hint documentation for all available options: http://www.jshint.com/docs/#options Below we have created a .jshintrc file that follows the recommendations set above in this article. You can place it in the root folder of your project and JSHint-avare code editors will notice it and follow it though all code in your project.

{ "camelcase" : true, "indent": 2, "undef": true, "quotmark": "single", "maxlen": 80, "trailing": true, "curly": true }

In addition to it you should add into your (browser-read) JavaScript files the following header:

/* jshint browser:true, jquery:true */

In your Node.js files you should add:

/*jshint node:true */

In any kind of JavaScript file it is also good to add the declaration:

'use strict';

This will affect both JSHint and your JavaScript engine, which will become less compliant but run your JavaScript faster.

Automatically JSHint files before Git commit

If you want to make sure that all of your JS code stays compliant to the style defined in your .jshintrc , you can set the following contents to your .git/hooks/pre-commit file, which is then run each time you try to commit any new of modified files to the project:

#!/bin/bash # Pre-commit Git hook to run JSHint on JavaScript files. # # If you absolutely must commit without testing, # use: git commit --no-verify filenames=($(git diff --cached --name-only HEAD)) which jshint &> /dev/null if [ $? -ne 0 ]; then echo "error: jshint not found" echo "install with: sudo npm install -g jshint" exit 1 fi for i in "${filenames[@]}" do if [[ $i =~ \.js$ ]]; then echo jshint $i jshint $i if [ $? -ne 0 ]; then exit 1 fi fi done

Happy coding!