Die meisten Codebasen sind voller neuer Ideen und Konzepte. Das bedeutet, dass Sie diese Ideen und Konzepte lernen müssen, wenn Sie mit einer Codebasis arbeiten möchten. Im Gegensatz zu Lehrbüchern besteht die zusätzliche Herausforderung bei Code darin, dass die Leute ihn nicht linear lesen werden. Sie werden irgendwo einsteigen und grob verstehen können, was vor sich geht. Drei Teile einer Codebasis helfen

Viel Klugheit wird auf diese Optimierungen gerichtet. Normalerweise brauchen Sie sie jedoch nicht. Einerseits werden JavaScript-Engines immer intelligenter und optimieren automatisch die Geschwindigkeit von Code, der etablierten Mustern folgt. Andererseits schreiben Minifier-Tools (Kapitel 32) Ihren Code neu, sodass er so klein wie möglich ist. In beiden Fällen sind Tools für Sie clever, damit Sie es nicht sein müssen.

Manchmal haben Sie keine andere Wahl, als die Leistung Ihres Codes zu optimieren. Wenn Sie dies tun, stellen Sie sicher, dass Sie die richtigen Teile messen und optimieren. In Browsern beziehen sich die Probleme oft auf DOM und HTML und nicht auf die Sprache selbst.

Ich mag relativ dichten Whitespace. Das Modell ist geschriebenes Englisch: Es gibt keine Leerzeichen nach einer öffnenden Klammer und vor einer schließenden Klammer. Und es gibt Leerzeichen nach Kommas:

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

Für anonyme Funktionen befolge ich die Regel von Douglas Crockford, nach dem Schlüsselwort function ein Leerzeichen zu setzen. Die Begründung ist, dass dies so aussieht, wie ein benannter Funktionsausdruck aussieht, wenn Sie den Namen entfernen

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

Dies hilft beim Lesen, da der Geltungsbereich des Operators leichter zu erkennen ist:

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

Ich deklariere nicht mehrere Variablen mit einer einzigen Deklaration:

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

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

Die Vorteile dieses Ansatzes sind, dass das Löschen, Einfügen und Umordnen von Zeilen einfacher ist und die Zeilen automatisch korrekt eingerückt werden.

Als Ergänzung zur vorherigen Regel: Deklarieren Sie nicht dieselbe Variable zweimal, in zwei verschiedenen Blöcken. Zum Beispiel

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

Der vorherige Code hat denselben Effekt und dieselbe Absicht wie der folgende Code, weshalb er so geschrieben werden sollte

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

Ich empfehle Ihnen,

Die Hauptvorteile sind

Bei Konstruktoren ist es wichtig, den Strict Mode zu verwenden, da er Sie vor dem Vergessen des new-Operators zur Instanziierung schützt. Und Sie sollten sich bewusst sein, dass Sie in einem Konstruktor jedes Objekt zurückgeben können. Weitere Tipps zur Verwendung von Konstruktoren werden in Tipps zur Implementierung von Konstruktoren erwähnt.

Ich finde, dass eine solche Konstruktoraufrufung mit Klammern sauberer aussieht

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

Verwenden Sie Klammern, damit sich zwei Operatoren nicht gegenseitig überlagern – das Ergebnis ist nicht immer das, was Sie vielleicht erwarten:

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

instanceof ist besonders knifflig

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

Methodenaufrufe nach einem Konstruktor finde ich jedoch unproblematisch

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

Konvertieren Sie einen Wert in einen Typ über Boolean, Number, String(), Object() (als Funktionen verwendet – verwenden Sie diese Funktionen niemals als Konstruktoren). Die Begründung ist, dass diese Konvention beschreibender ist:

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

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

this sollte sich nur auf den Empfänger des aktuellen Methodenaufrufs beziehen; es sollte nicht als impliziter Parameter missbraucht werden. Die Begründung ist, dass solche Funktionen leichter aufzurufen und zu verstehen sind. Ich mag es auch, objektorientierte und funktionale Mechanismen getrennt zu halten:

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

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

Dies ist selbsterklärender und sicherer als der Vergleich mit undefined oder die Prüfung auf Wahrheitswerte

// 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