13 Bemerkenswerte Punkte aus dem JavaScript Style Guide von Google

Für alle, die noch nicht damit vertraut sind, bietet Google einen Styleguide zum Schreiben von JavaScript an, in dem (wie Google glaubt) die besten Stilpraktiken für das Schreiben von sauberem, verständlichem Code aufgeführt sind.

Dies sind keine festen Regeln für das Schreiben von gültigem JavaScript, sondern nur Verbote für die Beibehaltung konsistenter und ansprechender Stiloptionen in Ihren Quelldateien. Dies ist besonders interessant für JavaScript, eine flexible und fehlerverzeihende Sprache, die eine Vielzahl von Stiloptionen ermöglicht.

Google und Airbnb haben zwei der beliebtesten Styleguides. Ich würde definitiv empfehlen, dass Sie sich beide ansehen, wenn Sie viel Zeit damit verbringen, JS zu schreiben.

Im Folgenden sind dreizehn der meiner Meinung nach interessantesten und relevantesten Regeln aus dem JS Style Guide von Google aufgeführt.

Sie befassen sich mit allem, von heiß umkämpften Themen (Tabulatoren versus Leerzeichen und die kontroverse Frage, wie Semikolons verwendet werden sollten) bis zu einigen weiteren undurchsichtigen Spezifikationen, die mich überraschten. Sie werden definitiv die Art und Weise ändern, wie ich meine JS schreibe.

Für jede Regel gebe ich eine Zusammenfassung der Spezifikation, gefolgt von einem unterstützenden Zitat aus dem Styleguide, das die Regel ausführlich beschreibt. Wo zutreffend, werde ich auch ein Beispiel für den Stil in der Praxis bereitstellen und ihn mit Code vergleichen, der nicht der Regel entspricht.

Verwenden Sie Leerzeichen, keine Tabulatoren

Abgesehen von der Zeilenabschlusssequenz ist das horizontale ASCII-Leerzeichen (0x20) das einzige Leerzeichen, das irgendwo in einer Quelldatei angezeigt wird. Dies bedeutet, dass… Tabulatorzeichen nicht zum Einrücken verwendet werden.

In der Anleitung wird später angegeben, dass Sie zum Einrücken zwei Leerzeichen (nicht vier) verwenden sollten.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Semikolons sind erforderlich

Jede Anweisung muss mit einem Semikolon abgeschlossen werden. Es ist verboten, sich auf das automatische Einfügen von Semikolons zu verlassen.

Obwohl ich mir nicht vorstellen kann, warum sich jemand gegen diese Idee ausspricht, wird die konsequente Verwendung von Semikolons in JS zur neuen Debatte über "Leerzeichen gegen Tabulatoren". Google tritt hier fest zur Verteidigung des Semikolons hervor.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

Verwenden Sie (noch) keine ES6-Module

Verwenden Sie noch keine ES6-Module (dh die Schlüsselwörter exportund import), da deren Semantik noch nicht abgeschlossen ist. Beachten Sie, dass diese Richtlinie erneut überprüft wird, sobald die Semantik vollständig dem Standard entspricht.
// Don't do this kind of thing yet:
//------ lib.js ------export function square(x) { return x * x;}export function diag(x, y) { return sqrt(square(x) + square(y));}//------ main.js ------import { square, diag } from 'lib';

Von der horizontalen Ausrichtung wird abgeraten (aber nicht verboten).

Diese Vorgehensweise ist zulässig, wird jedoch von Google Style im Allgemeinen nicht empfohlen . Es ist nicht einmal erforderlich, die horizontale Ausrichtung an Stellen beizubehalten, an denen sie bereits verwendet wurde.

Bei der horizontalen Ausrichtung wird eine variable Anzahl zusätzlicher Leerzeichen in Ihren Code eingefügt, damit bestimmte Token in vorherigen Zeilen direkt unter bestimmten anderen Token angezeigt werden.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

Benutze var nicht mehr

Deklarieren Sie alle lokalen Variablen mit entweder constoder let. Verwenden Sie standardmäßig const, es sei denn, eine Variable muss neu zugewiesen werden. Das varSchlüsselwort darf nicht verwendet werden.

Ich sehe immer noch Leute, die varin Codebeispielen auf StackOverflow und anderswo verwenden. Ich kann nicht sagen, ob es Leute gibt, die sich dafür einsetzen, oder ob es nur um alte Gewohnheiten geht, die hart sterben.

// badvar example = 42;
// goodlet example = 42;

Pfeilfunktionen werden bevorzugt

Pfeilfunktionen bieten eine präzise Syntax und beheben eine Reihe von Schwierigkeiten this. Bevorzugen Sie Pfeilfunktionen gegenüber dem functionSchlüsselwort, insbesondere für verschachtelte Funktionen

Ich bin ehrlich, ich dachte nur, dass Pfeilfunktionen großartig sind, weil sie prägnanter und schöner anzusehen sind. Es stellt sich heraus, dass sie auch einen ziemlich wichtigen Zweck erfüllen.

// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});

Verwenden Sie Vorlagenzeichenfolgen anstelle von Verkettung

Verwenden Sie Vorlagenzeichenfolgen (getrennt durch `) für die komplexe Verkettung von Zeichenfolgen, insbesondere wenn mehrere Zeichenfolgenliterale beteiligt sind. Vorlagenzeichenfolgen können mehrere Zeilen umfassen.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}

Verwenden Sie keine Zeilenfortsetzungen für lange Zeichenfolgen

Verwenden Sie keine Zeilenfortsetzungen (dh das Beenden einer Zeile innerhalb eines Zeichenfolgenliteral mit einem Backslash) in normalen oder Vorlagenzeichenfolgenliteralen. Obwohl ES5 dies zulässt, kann es zu kniffligen Fehlern kommen, wenn nach dem Schrägstrich ein Leerzeichen folgt, das für die Leser weniger offensichtlich ist.

Interessanterweise ist dies eine Regel, über die Google und Airbnb nicht einig sind (hier die Airbnb-Spezifikation).

Während Google empfiehlt, längere Zeichenfolgen zu verketten (siehe Abbildung unten), empfiehlt der Airbnb-Styleguide, im Wesentlichen nichts zu tun und lange Zeichenfolgen so lange wie nötig fortzusetzen.

// bad (sorry, this doesn't show up well on mobile)const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.';
// goodconst longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';

"For ... of" ist der bevorzugte Typ von "for loop".

Mit ES6 verfügt die Sprache nun über drei verschiedene Arten von forSchleifen. Es können jedoch alle verwendet werden for- ofSchleifen sollten nach Möglichkeit bevorzugt werden.

Dies ist seltsam, wenn Sie mich fragen, aber ich dachte, ich würde es einschließen, weil es ziemlich interessant ist, dass Google einen bevorzugten forSchleifentyp deklariert .

Ich hatte immer den Eindruck, dass for... inLoops besser für Objekte und for... ofbesser für Arrays geeignet sind. Ein "richtiges Werkzeug für den richtigen Job".

Obwohl Googles Spezifikation hier nicht unbedingt dieser Idee widerspricht, ist es dennoch interessant zu wissen, dass sie diese Schleife besonders bevorzugen.

Verwenden Sie eval () nicht

Verwenden Sie nicht evaloder den Function(...string)Konstruktor (außer für Code-Loader). Diese Funktionen sind potenziell gefährlich und funktionieren in CSP-Umgebungen einfach nicht.

Die MDN-Seite für hat eval()sogar einen Abschnitt namens "Eval nicht verwenden!"

// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

Konstanten sollten in ALL_UPPERCASE durch Unterstriche getrennt benannt werden

Konstante Namen verwenden CONSTANT_CASE: alle Großbuchstaben, wobei die Wörter durch Unterstriche getrennt sind.

Wenn Sie absolut sicher sind, dass sich eine Variable nicht ändern sollte, können Sie dies angeben, indem Sie den Namen der Konstante groß schreiben. Dies macht die Unveränderlichkeit der Konstante offensichtlich, da sie im gesamten Code verwendet wird.

Eine bemerkenswerte Ausnahme von dieser Regel ist, wenn die Konstante einen Funktionsbereich hat. In diesem Fall sollte es in camelCase geschrieben werden.

// badconst number = 5;
// goodconst NUMBER = 5;

Eine Variable pro Deklaration

Jede lokale Variablendeklaration deklariert nur eine Variable: Deklarationen, wie sie let a = 1, b = 2;nicht verwendet werden.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Verwenden Sie einfache Anführungszeichen, keine doppelten Anführungszeichen

Gewöhnliche Zeichenfolgenliterale werden durch einfache Anführungszeichen ( ') und nicht durch doppelte Anführungszeichen ( ") getrennt. Tipp: Wenn eine Zeichenfolge ein einfaches Anführungszeichen enthält, sollten Sie eine Vorlagenzeichenfolge verwenden, um zu vermeiden, dass Sie das Anführungszeichen umgehen müssen.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Eine letzte Anmerkung

Wie ich eingangs sagte, sind dies keine Mandate. Google ist nur einer von vielen Technologiegiganten, und dies sind nur Empfehlungen.

Trotzdem ist es interessant, sich die Stilempfehlungen anzusehen, die von einem Unternehmen wie Google herausgegeben werden, das viele brillante Leute beschäftigt, die viel Zeit damit verbringen, exzellenten Code zu schreiben.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.