Unser Code muss so sauber und einfach wie möglich zu lesen sein.

Das ist eigentlich die Kunst des Programmierens – eine komplexe Aufgabe so zu programmieren, dass sie sowohl korrekt als auch für Menschen lesbar ist. Ein guter Codestil hilft dabei sehr.

Syntax

Hier ist ein Spickzettel mit einigen vorgeschlagenen Regeln (siehe unten für weitere Details):

Lassen Sie uns nun die Regeln und Gründe dafür im Detail besprechen.

Geschweifte Klammern

In den meisten JavaScript–Projekten werden geschweifte Klammern im „ägyptischen“ Stil geschrieben, wobei die öffnende Klammer in derselben Zeile wie das entsprechende Schlüsselwort steht – nicht in einer neuen Zeile. Vor der öffnenden Klammer sollte auch ein Leerzeichen stehen:

if (condition) { // do this // ...and that // ...and that}

Ein einzeiliges Konstrukt wie if (condition) doSomething() ist ein wichtiger Randfall. Sollten wir überhaupt Zahnspangen verwenden?

Hier sind die kommentierten Varianten, damit Sie ihre Lesbarkeit selbst beurteilen können:

Für einen sehr kurzen Code ist eine Zeile erlaubt, zB if (cond) return null. Ein Codeblock (die letzte Variante) ist jedoch normalerweise besser lesbar.

Zeilenlänge

Niemand liest gerne eine lange horizontale Codezeile. Es ist am besten, sie zu teilen.

Zum Beispiel:

// backtick quotes ` allow to split the string into multiple lineslet str = ` ECMA International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.`;

Und für if Anweisungen:

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

Die maximale Zeilenlänge sollte auf Teamebene vereinbart werden. Es sind normalerweise 80 oder 120 Zeichen.

Einrückungen

Es gibt zwei Arten von Einrückungen:

• Horizontale Einrückungen: 2 oder 4 Leerzeichen.

  Eine horizontale Einrückung erfolgt entweder mit 2 oder 4 Leerzeichen oder dem horizontalen Tabulatorsymbol (Tabulatortaste). Welches zu wählen ist, ist ein alter heiliger Krieg. Räume sind heutzutage häufiger.

  Ein Vorteil von Leerzeichen gegenüber Tabulatoren ist, dass Leerzeichen flexiblere Konfigurationen von Einzügen ermöglichen als das Tabulatorsymbol.

  Zum Beispiel können wir die Parameter wie folgt an der öffnenden Klammer ausrichten:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• Vertikale Einrückungen: leere Zeilen zum Aufteilen von Code in logische Blöcke.

  Selbst eine einzelne Funktion kann oft in logische Blöcke unterteilt werden. Im folgenden Beispiel werden die Initialisierung von Variablen, die Hauptschleife und die Rückgabe des Ergebnisses vertikal aufgeteilt:

  function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}

  Fügen Sie eine zusätzliche neue Zeile ein, um den Code besser lesbar zu machen. Es sollten nicht mehr als neun Codezeilen ohne vertikalen Einzug vorhanden sein.

Semikolons

Nach jeder Anweisung sollte ein Semikolon vorhanden sein, auch wenn es möglicherweise übersprungen werden könnte.

Es gibt Sprachen, in denen ein Semikolon wirklich optional ist und selten verwendet wird. In JavaScript gibt es jedoch Fälle, in denen ein Zeilenumbruch nicht als Semikolon interpretiert wird, wodurch der Code fehleranfällig wird. Weitere Informationen dazu finden Sie im Kapitel Codestruktur.

Wenn Sie ein erfahrener JavaScript-Programmierer sind, können Sie einen Code-Stil ohne Semikolon wie StandardJS wählen. Andernfalls verwenden Sie am besten Semikolons, um mögliche Fallstricke zu vermeiden. Die Mehrheit der Entwickler setzen Semikolons.

Ebenen verschachteln

Versuchen Sie zu vermeiden, Code zu viele Ebenen tief zu verschachteln.

Zum Beispiel ist es in der Schleife manchmal eine gute Idee, die continue Direktive zu verwenden, um zusätzliche Verschachtelung zu vermeiden.

Anstatt beispielsweise eine verschachtelte if Bedingung wie folgt hinzuzufügen:

for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

Wir können:

for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

Ähnliches kann mit if/else und return gemacht werden.

Zum Beispiel sind zwei Konstrukte unten identisch.

Option 1:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); } else { let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result; }}

Option 2:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); return; } let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result;}

Der zweite ist besser lesbar, da der „Sonderfall“ von n < 0 wird frühzeitig behandelt. Sobald die Überprüfung abgeschlossen ist, können wir zum „Haupt“ -Codefluss übergehen, ohne dass eine zusätzliche Verschachtelung erforderlich ist.

Funktionsplatzierung

Wenn Sie mehrere „Hilfsfunktionen“ und den Code, der sie verwendet, schreiben, gibt es drei Möglichkeiten, die Funktionen zu organisieren.

Meistens wird die zweite Variante bevorzugt.

Das liegt daran, dass wir beim Lesen von Code zuerst wissen wollen, was er tut. Wenn der Code zuerst geht, wird es von Anfang an klar. Dann müssen wir die Funktionen möglicherweise überhaupt nicht lesen, insbesondere wenn ihre Namen beschreiben, was sie tatsächlich tun.

Styleguides

Ein Styleguide enthält allgemeine Regeln zum „Schreiben“ von Code, z. B. welche Anführungszeichen verwendet werden sollen, wie viele Leerzeichen eingerückt werden sollen, die maximale Zeilenlänge usw. Viele Kleinigkeiten.

Wenn alle Mitglieder eines Teams denselben Styleguide verwenden, sieht der Code einheitlich aus, unabhängig davon, welches Teammitglied ihn geschrieben hat.

Natürlich kann ein Team immer seinen eigenen Styleguide schreiben, aber normalerweise ist das nicht nötig. Es stehen viele vorhandene Anleitungen zur Auswahl.

Einige beliebte Optionen:Das ist der Grund, warum wir uns für die Verwendung von JavaScript entschieden haben.JS

Wenn Sie ein Anfänger sind, beginnen Sie mit dem Spickzettel am Anfang dieses Kapitels. Dann können Sie andere Styleguides durchsuchen, um weitere Ideen aufzunehmen und zu entscheiden, welche Ihnen am besten gefällt.

Automatisierte Linter

Linter sind Werkzeuge, die automatisch den Stil Ihres Codes überprüfen und Verbesserungsvorschläge machen können.

Das Tolle an ihnen ist, dass Style-Checking auch einige Fehler finden kann, wie Tippfehler in Variablen- oder Funktionsnamen. Aufgrund dieser Funktion wird die Verwendung eines Linters empfohlen, auch wenn Sie sich nicht an einen bestimmten „Codestil“ halten möchten.

Hier sind einige bekannte Linting-Tools:

• JSLint – einer der ersten Linter.
• JSHint – mehr Einstellungen als JSLint.
• ESLint – wahrscheinlich das neueste.

Alle von ihnen können den Job machen. Der Autor verwendet ESLint.

Die meisten Linter sind in viele gängige Editoren integriert: aktivieren Sie einfach das Plugin im Editor und konfigurieren Sie den Stil.

Zum Beispiel sollten Sie für ESLint Folgendes tun:

1. Install Node .js.
2. Installieren Sie ESLint mit dem Befehl npm install -g eslint (npm ist ein JavaScript-Paketinstallationsprogramm).
3. Erstellen Sie eine Konfigurationsdatei mit dem Namen .eslintrc im Stammverzeichnis Ihres JavaScript-Projekts (in dem Ordner, der alle Ihre Dateien enthält).
4. Installieren/aktivieren Sie das Plugin für Ihren Editor, das in ESLint integriert ist. Die meisten Redakteure haben einen.

Hier ist ein Beispiel für eine .eslintrc Datei:

{ "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}

Hier bedeutet die Direktive "extends", dass die Konfiguration auf dem Einstellungssatz „eslint:recommended“ basiert. Danach spezifizieren wir unsere eigenen.

Es ist auch möglich, Stilregelsätze aus dem Web herunterzuladen und stattdessen zu erweitern. Weitere Informationen zur Installation finden Sie unter http://eslint.org/docs/user-guide/getting-started.

Auch bestimmte IDEs haben eingebaute Linting, die bequem ist, aber nicht so anpassbar wie ESLint.

Zusammenfassung

Alle Syntaxregeln, die in diesem Kapitel (und in den Styleguides, auf die verwiesen wird) beschrieben werden, zielen darauf ab, die Lesbarkeit Ihres Codes zu verbessern. Alle von ihnen sind umstritten.

Wenn wir darüber nachdenken, „besseren“ Code zu schreiben, sollten wir uns folgende Fragen stellen: „Was macht den Code lesbarer und verständlicher?“ und „Was kann uns helfen, Fehler zu vermeiden?“ Dies sind die wichtigsten Dinge, die Sie bei der Auswahl und Diskussion von Codestilen beachten sollten.

Wenn Sie beliebte Styleguides lesen, können Sie sich über die neuesten Ideen zu Codestiltrends und Best Practices auf dem Laufenden halten.