crockford-good-parts

name	crockford-good-parts
description	Write JavaScript code in the style of Douglas Crockford, author of "JavaScript: The Good Parts". Emphasizes using only the reliable subset of JavaScript, avoiding problematic features, and writing clear, maintainable code. Use when writing robust, quality JavaScript.

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() {
     person = .(personPrototype);
    person. = name;
    person. = age;
     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