For anyone who isn’t already familiar with it, Google puts out a style guide for writing JavaScript that lays out (what Google believes to be) the best stylistic practices for writing clean, understandable code.

These are not hard and fast rules for writing valid JavaScript, only proscriptions for maintaining consistent and appealing style choices throughout your source files. This is particularly interesting for JavaScript, which is a flexible and forgiving language that allows for a wide variety of stylistic choices.

Google and Airbnb have two of the most popular style guides out there. I’d definitely recommend you check out both of them if you spend much time writing JS.

The following are thirteen of what I think are the most interesting and relevant rules from Google’s JS Style Guide.

They deal with everything from hotly contested issues (tabs versus spaces, and the controversial issue of how semicolons should be used), to a few more obscure specifications which surprised me. They will definitely change the way I write my JS going forward.

For each rule, I’ll give a summary of the specification, followed by a supporting quote from the style guide that describes the rule in detail. Where applicable, I’ll also provide an example of the style in practice, and contrast it with code that does not follow the rule.

Use spaces, not tabs

// bad
function foo() {
&#x2219;&#x2219;&#x2219;&#x2219;let name;
}

// bad
function bar() {
&#x2219;let name;
}

// good
function baz() {
&#x2219;&#x2219;let name;
}

Semicolons ARE required

// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = &apos;vader&apos;)


// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
  jedi.father = &apos;vader&apos;;
});

Don’t use ES6 modules (yet)

// Don't do this kind of thing yet:

//------ lib.js ------
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';

Horizontal alignment is discouraged (but not forbidden)

// bad
{
  tiny:   42,  
  longer: 435, 
};


// good
{
  tiny: 42, 
  longer: 435,
};

Don’t use var anymore

// bad
var example = 42;

// good
let example = 42;

Arrow functions are preferred

// bad
[1, 2, 3].map(function (x) {
  const y = x + 1;
  return x * y;
});

// good
[1, 2, 3].map((x) => {
  const y = x + 1;
  return x * y;
});

Use template strings instead of concatenation

// bad
function sayHi(name) {
  return &apos;How are you, &apos; + name + &apos;?&apos;;
}

// bad
function sayHi(name) {
  return [&apos;How are you, &apos;, name, &apos;?&apos;].join();
}

// bad
function sayHi(name) {
  return `How are you, ${ name }?`;
}

// good
function sayHi(name) {
  return `How are you, ${name}?`;
}

Don’t use line continuations for long strings

While Google recommends concatenating longer strings (as shown below) Airbnb’s style guide recommends essentially doing nothing, and allowing long strings to go on as long as they need to.

// bad (sorry, this doesn&apos;t show up well on mobile)
const longString = &apos;This is a very long string that \
    far exceeds the 80 column limit. It unfortunately \
    contains long stretches of spaces due to how the \
    continued lines are indented.&apos;;


// good
const longString = &apos;This is a very long string that &apos; + 
    &apos;far exceeds the 80 column limit. It does not contain &apos; + 
    &apos;long stretches of spaces since the concatenated &apos; +
    &apos;strings are cleaner.&apos;;

“for… of” is the preferred type of ‘for loop’

I was always under the impression that for... in loops were better for objects, while for... of were better suited to arrays. A ‘right tool for the right job’ type situation.

While Google’s specification here doesn’t necessarily contradict that idea, it is still interesting to know they have a preference for this loop in particular.

Don’t use eval()

let obj = { a: 20, b: 30 };
let propName = getPropName();  // returns "a" or "b"
eval( &apos;var result = obj.&apos; + propName );

let obj = { a: 20, b: 30 };
let propName = getPropName();  // returns "a" or "b"
let result = obj[ propName ];  //  obj[ "a" ] is the same as obj.a

Constants should be named in ALL_UPPERCASE separated by underscores

A notable exception to this rule is if the constant is function-scoped. In this case it should be written in camelCase.

// bad
const number = 5;


// good
const NUMBER = 5;

One variable per declaration

// bad
let a = 1, b = 2, c = 3;

// good
let a = 1;
let b = 2;
let c = 3;

Use single quotes, not double quotes

&apos;Say it ain\u0027t so.&apos;;

// good
let directive = &apos;No identification of self or mission.&apos;;

// good
let saying = `Say it ain&apos;t so`;

A final note

As I said in the beginning, these are not mandates. Google is just one of many tech giants, and these are just recommendations.

That said, it is interesting to look at the style recommendations that are put out by a company like Google, which employs a lot of brilliant people who spend a lot of time writing excellent code.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.

#javascript

Top 13 Noteworthy Points from Google’s JavaScript Style Guide