Most code bases are filled with new ideas and concepts. That means that if you want to work with a code base, you need to learn those ideas and concepts. In contrast to textbooks, the added challenge with code is that people will not read it linearly. They will jump in anywhere and should be able to roughly understand what is going on. Three parts of a code base help:

Much cleverness is directed at these optimizations. However, you normally don’t need them. On one hand, JavaScript engines are becoming increasingly smart and automatically optimize the speed of code that follows established patterns. On the other hand, minification tools (Chapter 32) rewrite your code so that it is as small as possible. In both cases, tools are clever for you, so that you don’t have to be.

Sometimes you have no choice but to optimize the performance of your code. If you do, be sure to measure and optimize the right pieces. In browsers, the problems are often related to DOM and HTML and not the language proper.

I like relatively tight whitespace. The model is written English: there are no spaces after an opening parenthesis and before a closing parenthesis. And there are spaces after commas:

var result = foo('a', 'b');
var arr = [ 1, 2, 3 ];
if (flag) {
    ...
}

For anonymous functions, I follow Douglas Crockford’s rule of having a space after the keyword function. The rationale is that this is what a named function expression looks like if you remove the name:

function foo(arg) { ... }  // named function expression
function (arg) { ... }     // anonymous function expression

This helps with reading, because it is easier to make out the scope of the operator:

return result ? result : theDefault;  // no
return (result ? result : theDefault);  // yes

I don’t declare multiple variables with a single declaration:

// no
var foo = 3,
    bar = 2,
    baz;

// yes
var foo = 3;
var bar = 2;
var baz;

The advantages of this approach are that deleting, inserting, and rearranging lines is simpler and the lines are automatically indented correctly.

As an addendum to the previous rule: don’t declare the same variable twice, in two different blocks. For example:

// Don’t do this
if (v) {
    var x = v;
} else {
    var x = 10;
}
doSomethingWith(x);

The preceding code has the same effect and intention as the following code, which is why it should be written that way:

var x;
if (v) {
    x = v;
} else {
    x = 10;
}
doSomethingWith(x);

I recommend that you:

The main advantages of doing so are:

For constructors, it is important to use strict mode, because it protects you against forgetting the new operator for instantiation. And you should be aware that you can return any object in a constructor. More tips for using constructors are mentioned in Tips for Implementing Constructors.

I find that such a constructor invocation looks cleaner with parentheses:

var foo = new Foo;  // no
var foo = new Foo();  // yes

Use parens so that two operators don’t compete with each other—the result is not always what you might expect:

> false && true || true
true
> false && (true || true)
false
> (false && true) || true
true

instanceof is especially tricky:

> ! {} instanceof Array
false
> (!{}) instanceof Array
false
> !({} instanceof Array)
true

However, I find method calls after a constructor unproblematic:

new Foo().bar().baz();  // ok
(new Foo()).bar().baz();  // not necessary

Coerce a value to a type via Boolean, Number, String(), Object() (used as functions—never use those functions as constructors). The rationale is that this convention is more descriptive:

> +'123'  // no
123
> Number('123')  // yes
123

> ''+true  // no
'true'
> String(true)  // yes
'true'

this should refer only to the receiver of the current method invocation; it should not be abused as an implicit parameter. The rationale is that such functions are easier to call and understand. I also like to keep object-oriented and functional mechanisms separate:

// Avoid:
function handler() {
    this.logError(...);
}

// Prefer:
function handler(context) {
    context.logError(...);
}

This is more self-explanatory and safer than comparing with undefined or checking for truthiness:

// All properties:
if (obj.foo)  // no
if (obj.foo !== undefined)  // no
if ('foo' in obj) ... // yes

// Own properties:
if (obj.hasOwnProperty('foo')) ... // risky for arbitrary objects
if (Object.prototype.hasOwnProperty.call(obj, 'foo')) ... // safe