Douglas Crockford Style Guide

Overview

Douglas Crockford is the author of "JavaScript: The Good Parts" and creator of JSON. His philosophy centers on using only the reliable, well-designed parts of JavaScript while strictly avoiding the problematic features.

Core Philosophy

"JavaScript has some extraordinarily good parts. In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders."

"It is better to be clear than clever."

Crockford believes that JavaScript, despite its flaws, contains a powerful and beautiful language—if you know which parts to use.

Design Principles

1. Use the Good Parts: Stick to the reliable subset of the language.

2. Avoid the Bad Parts: Don't use features that are error-prone or confusing.

3. Clarity Over Cleverness: Code should be immediately understandable.

4. Lint Everything: Use tools like JSLint to enforce quality.

When Writing Code

Always

• Use

  ===

  and

  !==

  (strict equality)
• Declare variables at the top of their scope
• Use a single

  var

  /

  let

  /

  const

  statement per scope (Crockford's older style)
• Put braces on the same line as control statements
• Use JSLint/ESLint and fix all warnings
• Prefer named functions over anonymous functions

Never

• Use

  ==

  or

  !=

  (type coercion equality)
• Use

  eval()

  or

  Function()

  constructor
• Use

  with

  statement
• Use

  ++

  or

  --

  (prefer

  += 1

  )
• Rely on automatic semicolon insertion
• Use bitwise operators for non-bitwise operations
• Use

  new

  for primitives (

  new String

  ,

  new Number

  ,

  new Boolean

  )

Prefer

• Object.create()

  over constructor functions
• Object literals over

  new Object()

• Array literals over

  new Array()

• Array.isArray()

  over

  instanceof Array

• Explicit returns over implicit
• Named functions over arrow functions for methods

Code Patterns

Object Creation

// BAD: Constructor function with new
function Person(name, age) {
    this.name = name;
    this.age = age;
}
Person.prototype.greet = function () {
    return 'Hello, ' + this.name;
};
var person = new Person('Alice', 30);

// GOOD: Factory function (no new required)
function createPerson(name, age) {
    return {
        name: name,
        age: age,
        greet: function () {
            return 'Hello, ' + name;  // Closure for privacy
        }
    };
}
var person = createPerson('Alice', 30);


// BETTER: Object.create for inheritance
var personPrototype = {
    greet: function () {
        return 'Hello, ' + this.name;
    }
};

function createPerson(name, age) {
    var person = Object.create(personPrototype);
    person.name = name;
    person.age = age;
    return person;
}

Module Pattern

// The module pattern for encapsulation
var counter = (function () {
    var count = 0;  // Private variable

    return {
        increment: function () {
            count += 1;
            return count;
        },
        decrement: function () {
            count -= 1;
            return count;
        },
        getCount: function () {
            return count;
        }
    };
}());

counter.increment();  // 1
counter.getCount();   // 1
// count is not accessible directly

Strict Equality

// BAD: Type coercion surprises
'' == false      // true (!)
0 == ''          // true (!)
null == undefined  // true (!)

// GOOD: Strict equality, no surprises
'' === false     // false
0 === ''         // false
null === undefined  // false

// Always use strict equality
if (value === null) {
    // handle null
}

if (typeof value === 'undefined') {
    // handle undefined
}

Function Best Practices

// BAD: Anonymous function
var numbers = [1, 2, 3];
numbers.map(function (n) {
    return n * 2;
});

// GOOD: Named function (better stack traces, self-documenting)
function double(n) {
    return n * 2;
}
numbers.map(double);


// BAD: Relying on hoisting
greet('Alice');
function greet(name) {
    return 'Hello, ' + name;
}

// GOOD: Define before use
function greet(name) {
    return 'Hello, ' + name;
}
greet('Alice');

Array and Object Literals

// BAD: Constructor forms
var arr = new Array();
var obj = new Object();
var str = new String('hello');

// GOOD: Literal forms
var arr = [];
var obj = {};
var str = 'hello';


// BAD: Array constructor ambiguity
var a = new Array(3);     // [undefined, undefined, undefined]
var b = new Array(1, 2);  // [1, 2]

// GOOD: Always predictable
var a = [undefined, undefined, undefined];
var b = [1, 2];

Error Handling

// Proper try-catch usage
function parseJSON(text) {
    try {
        return JSON.parse(text);
    } catch (e) {
        console.error('Invalid JSON:', e.message);
        return null;
    }
}

// Throw with Error objects, not strings
// BAD:
throw 'Something went wrong';

// GOOD:
throw new Error('Something went wrong');

The Bad Parts to Avoid

1. Global Variables: Pollute the namespace, cause conflicts

2. eval()

   : Security risk, performance killer

3. with

   : Ambiguous scope, deprecated

4. ==

   and

   !=

   : Type coercion causes bugs

5. ++

   and

   --

   : Encourage trickery
6. Bitwise Operators: Rarely needed, often misused

7. void

   : Confusing and unnecessary
8. Typed Wrappers:

   new String()

   ,

   new Number()

   ,

   new Boolean()

9. arguments

   : Use rest parameters instead
10. Automatic Semicolon Insertion: Be explicit

Mental Model

Crockford approaches JavaScript by asking:

1. Is this a good part? If not, avoid it entirely
2. Would a bug here be obvious? If not, use a safer pattern
3. Can this be linted? If JSLint complains, fix it
4. Is this clear to readers? Clarity trumps cleverness

Signature Crockford Moves

• Factory functions instead of constructors
• IIFE module pattern for encapsulation
• Strict equality everywhere
• Object literals for all object creation
• Named functions for debuggability
• JSLint compliance as non-negotiable