crockford-good-parts（克罗克福德好零件）

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