Lexikalische Grammatik

Formatsteuerzeichen

Formatsteuerzeichen haben keine visuelle Darstellung, werden aber zur Steuerung der Interpretation des Textes verwendet.

Im JavaScript-Quelltext werden <ZWNJ> und <ZWJ> als Identifier-Teile behandelt, whrend <BOM> (auch als zero-width no-break space <ZWNBSP> bezeichnet, wenn nicht am Anfang des Textes) als Leerzeichen behandelt wird.

Leerzeichen

Leerzeichen-Zeichen verbessern die Lesbarkeit des Quelltextes und trennen Tokens voneinander. Diese Zeichen sind fr die Funktionalitt des Codes in der Regel nicht erforderlich. Minimierungstools werden oft verwendet, um Leerzeichen zu entfernen und somit die Menge der zu bertragenden Daten zu reduzieren.

Zeilenabschlsse

Zustzlich zu Leerzeichen-Zeichen werden Zeilenabschlusszeichen verwendet, um die Lesbarkeit des Quelltextes zu verbessern. In einigen Fllen knnen Zeilenabschlusszeichen jedoch die Ausfhrung von JavaScript-Code beeinflussen, da sie in einigen wenigen Fllen verboten sind. Zeilenabschlsse beeinflussen auch den Prozess der automatischen Einfgung von Semikola.

Auerhalb des Kontexts der lexikalischen Grammatik werden Leerzeichen und Zeilenabschlsse oft verwechselt. Zum Beispiel entfernt String.prototype.trim() alle Leerzeichen und Zeilenabschlsse am Anfang und Ende eines Strings. Die \s Zeichenklasse-Entfernung in regulren Ausdrcken entspricht allen Leerzeichen und Zeilenabschlssen.

Nur die folgenden Unicode-Codepunkte werden in ECMAScript als Zeilenabschlsse behandelt, andere zeilenbrechende Zeichen werden als Leerzeichen behandelt (zum Beispiel wird Next Line, NEL, U+0085 als Leerzeichen betrachtet).

Kommentare

Kommentare werden verwendet, um Hinweise, Anmerkungen, Vorschlge oder Warnungen zu JavaScript-Code hinzuzufgen. Dies kann das Lesen und Verstehen erleichtern. Sie knnen auch verwendet werden, um Code zu deaktivieren, um zu verhindern, dass er ausgefhrt wird; dies kann ein wertvolles Debugging-Werkzeug sein.

JavaScript bietet zwei langjhrige Mglichkeiten, Kommentare zu Code hinzuzufgen: Zeilenkommentare und Blockkommentare. Zustzlich gibt es eine spezielle Hashbang-Kommentar-Syntax.

Zeilenkommentare

Die erste Mglichkeit ist der // Kommentar; dieser verwandelt den gesamten Text, der ihm auf derselben Zeile folgt, in einen Kommentar. Zum Beispiel:

function comment() {
  // This is a one line JavaScript comment
  console.log("Hello world!");
}
comment();

Blockkommentare

Die zweite Mglichkeit ist der /* */ Stil, der viel flexibler ist.

Zum Beispiel knnen Sie ihn in einer einzelnen Zeile verwenden:

function comment() {
  /* This is a one line JavaScript comment */
  console.log("Hello world!");
}
comment();

Sie knnen auch mehrzeilige Kommentare machen, wie diesen:

function comment() {
  /* This comment spans multiple lines. Notice
     that we don't need to end the comment until we're done. */
  console.log("Hello world!");
}
comment();

Sie knnen ihn auch mitten in einer Zeile verwenden, wenn Sie mchten; dies kann jedoch Ihren Code schwieriger lesbar machen, daher sollte dies mit Vorsicht verwendet werden:

function comment(x) {
  console.log("Hello " + x /* insert the value of x */ + " !");
}
comment("world");

Auerdem knnen Sie ihn verwenden, um Code zu deaktivieren, um zu verhindern, dass er ausgefhrt wird, indem Sie den Code in einem Kommentar einschlieen, wie hier:

function comment() {
  /* console.log("Hello world!"); */
}
comment();

In diesem Fall wird der console.log()-Aufruf nie erteilt, da er sich innerhalb eines Kommentars befindet. Jede Anzahl von Codezeilen kann auf diese Weise deaktiviert werden.

Blockkommentare, die mindestens einen Zeilenabschluss enthalten, verhalten sich wie Zeilenabschlsse bei der automatischen Einfgung von Semikola.

Hashbang-Kommentare

Es gibt eine spezielle dritte Kommentarsyntax, den Hashbang-Kommentar. Ein Hashbang-Kommentar verhlt sich genau wie ein einzelner Kommentar (//), nur dass er mit #! beginnt und nur am absoluten Anfang eines Skripts oder Moduls gltig ist. Beachten Sie auch, dass kein Leerzeichen irgendeiner Art vor dem #! erlaubt ist. Der Kommentar besteht aus allen Zeichen nach #! bis zum Ende der ersten Zeile; nur ein solcher Kommentar ist erlaubt.

Hashbang-Kommentare in JavaScript hneln Shebangs in Unix, die den Pfad zu einem bestimmten JavaScript-Interpreter bereitstellen, den Sie zur Ausfhrung des Skripts verwenden mchten. Bevor der Hashbang-Kommentar standardisiert wurde, war er bereits faktisch in Nicht-Browser-Hosts wie Node.js implementiert, wo er aus dem Quelltext gestrichen wurde, bevor er an die Engine bergeben wurde. Ein Beispiel ist wie folgt:

#!/usr/bin/env node

console.log("Hello world");

Der JavaScript-Interpreter behandelt ihn als normalen Kommentar er hat nur semantische Bedeutung fr die Shell, wenn das Skript direkt in einer Shell ausgefhrt wird.

Sie sollten den #!-Kommentarstil nur verwenden, um einen JavaScript-Interpreter anzugeben. In allen anderen Fllen verwenden Sie einfach einen //-Kommentar (oder einen mehrzeiligen Kommentar).

Bezeichner

Ein Bezeichner wird verwendet, um einen Wert mit einem Namen zu verknpfen. Bezeichner knnen an verschiedenen Stellen verwendet werden:

const decl = 1; // Variable declaration (may also be `let` or `var`)
function fn() {} // Function declaration
const obj = { key: "value" }; // Object keys
// Class declaration
class C {
  #priv = "value"; // Private field
}
lbl: console.log(1); // Label

In JavaScript bestehen Bezeichner blicherweise aus alphanumerischen Zeichen, Unterstrichen (_) und Dollarzeichen ($). Bezeichner drfen nicht mit Zahlen beginnen. JavaScript-Bezeichner sind jedoch nicht nur auf ASCII beschrnkt es sind auch viele Unicode-Codepunkte erlaubt. Genauer gesagt:

• Startzeichen knnen jedes Zeichen in der ID_Start Kategorie sowie _ und $ sein.
• Nach dem ersten Zeichen knnen Sie jedes Zeichen in der ID_Continue Kategorie sowie U+200C (ZWNJ) und U+200D (ZWJ) verwenden.

Darber hinaus erlaubt JavaScript die Verwendung von Unicode-Escape-Sequenzen in Form von \u0000 oder \u{000000} in Bezeichnern, die denselben String-Wert wie die tatschlichen Unicode-Zeichen kodieren. Zum Beispiel sind und \u4f60\u597d die gleichen Bezeichner:

const  = "Hello";
console.log(\u4f60\u597d); // Hello

Jedoch akzeptieren nicht alle Stellen den vollstndigen Bereich der Bezeichner. Bestimmte Syntaxen wie Funktionsdeklarationen, Funktionsausdrcke und Variablendeklarationen erfordern die Verwendung von Bezeichnernamen, die keine reservierten Wrter sind.

function import() {} // Illegal: import is a reserved word.

Am bemerkenswertesten ist, dass private Elemente und Objekteigenschaften reservierte Wrter erlauben.

const obj = { import: "value" }; // Legal despite `import` being reserved
class C {
  #import = "value";
}

Schlsselwrter

Schlsselwrter sind Token, die wie Bezeichner aussehen, aber in JavaScript eine spezielle Bedeutung haben. Zum Beispiel zeigt das Schlsselwort async vor einer Funktionsdeklaration an, dass die Funktion asynchron ist.

Einige Schlsselwrter sind reserviert, was bedeutet, dass sie nicht als Bezeichner fr Variablendeklarationen, Funktionsdeklarationen usw. verwendet werden knnen. Sie werden oft als reservierte Wrter bezeichnet. Eine Liste dieser reservierten Wrter wird unten bereitgestellt. Nicht alle Schlsselwrter sind reserviert zum Beispiel kann async berall als Bezeichner verwendet werden. Einige Schlsselwrter sind nur kontextuell reserviert zum Beispiel ist await nur innerhalb des Krpers einer asynchronen Funktion reserviert, und let ist nur im Strict Mode-Code oder const- und let-Deklarationen reserviert.

Bezeichner werden immer nach ihrem Stringwert verglichen, sodass Escape-Sequenzen interpretiert werden. Zum Beispiel ist dies immer noch ein Syntaxfehler:

const els\u{65} = 1;
// `els\u{65}` encodes the same identifier as `else`

Reservierte Wrter

Diese Schlsselwrter knnen nirgendwo in JavaScript-Quelltext als Bezeichner fr Variablen, Funktionen, Klassen usw. verwendet werden.

• break
• case
• catch
• class
• const
• continue
• debugger
• default
• delete
• do
• else
• export
• extends
• false
• finally
• for
• function
• if
• import
• in
• instanceof
• new
• null
• return
• super
• switch
• this
• throw
• true
• try
• typeof
• var
• void
• while
• with

Die folgenden sind nur reserviert, wenn sie im Strict Mode-Code gefunden werden:

• let (auch in const, let und Klassendeklarationen reserviert)
• static
• yield (auch in Body von Generatorfunktionen reserviert)

Die folgenden sind nur reserviert, wenn sie im Modulcode oder in asynchronen Funktionskrpern gefunden werden:

• await

Knftige reservierte Wrter

Die folgenden sind von der ECMAScript-Spezifikation als zuknftige Schlsselwrter reserviert. Sie haben derzeit keine spezielle Funktionalitt, knnten dies aber in Zukunft haben, daher knnen sie nicht als Bezeichner verwendet werden.

Diese sind immer reserviert:

• enum

Die folgenden sind nur reserviert, wenn sie im Strict Mode-Code gefunden werden:

• implements
• interface
• package
• private
• protected
• public

Knftige reservierte Wrter in lteren Standards

Die folgenden sind von lteren ECMAScript-Spezifikationen (ECMAScript 1 bis 3) als zuknftige Schlsselwrter reserviert.

• abstract
• boolean
• byte
• char
• double
• final
• float
• goto
• int
• long
• native
• short
• synchronized
• throws
• transient
• volatile

Bezeichner mit speziellen Bedeutungen

Einige Bezeichner haben in bestimmten Kontexten ohne eine Art reserviertes Wort eine besondere Bedeutung. Dazu gehren:

• arguments (kein Schlsselwort, aber kann nicht als Bezeichner im Strict Mode deklariert werden)
• as (import * as ns from "mod")
• async
• eval (kein Schlsselwort, aber kann nicht als Bezeichner im Strict Mode deklariert werden)
• from (import x from "mod")
• get
• of
• set

Literale

Null-Literal

Siehe auch null fr mehr Informationen.

null

Boolean-Literal

Siehe auch Boolean-Typ fr mehr Informationen.

true
false

Numerische Literale

Die Number und BigInt Typen verwenden numerische Literale.

Dezimal

1234567890
42

Dezimal-Literale knnen mit einer Null (0) beginnen, gefolgt von einer anderen dezimalen Ziffer, aber wenn alle Ziffern nach der fhrenden 0 kleiner als 8 sind, wird die Zahl als Oktalzahl interpretiert. Dies wird als veraltete Syntax betrachtet, und Zahl-Literale mit dem Prfix 0, ob sie als Oktal- oder Dezimalzahl interpretiert werden, verursachen einen Syntaxfehler im Strict Mode verwenden Sie also stattdessen das 0o Prfix.

0888 // 888 parsed as decimal
0777 // parsed as octal, 511 in decimal

Exponential

Das Dezimal-Exponential-Literal wird durch das folgende Format spezifiziert: beN; wobei b eine Basiszahl (ganz oder gleitend) ist, gefolgt von einem E- oder e-Zeichen (das als Trenn- oder Exponentialindikator dient) und N, das entweder ein Exponent oder Potenzzahl ist eine ganze Zahl mit Vorzeichen.

0e-5   // 0
0e+5   // 0
5e1    // 50
175e-2 // 1.75
1e3    // 1000
1e-3   // 0.001
1E3    // 1000

Binr

Die Binrzahl-Syntax verwendet eine fhrende Null, gefolgt von einem Klein- oder Grobuchstaben "B" (0b oder 0B). Ein beliebiges Zeichen nach dem 0b, das nicht 0 oder 1 ist, beendet die Literalsequenz.

0b10000000000000000000000000000000 // 2147483648
0b01111111100000000000000000000000 // 2139095040
0B00000000011111111111111111111111 // 8388607

Oktal

Die Oktalzahl-Syntax verwendet eine fhrende Null, gefolgt von einem Klein- oder Grobuchstaben "O" (0o oder 0O). Ein beliebiges Zeichen nach dem 0o, das auerhalb des Bereichs (01234567) liegt, beendet die Literalsequenz.

0O755 // 493
0o644 // 420

Hexadezimal

Die Hexadezimalzahl-Syntax verwendet eine fhrende Null, gefolgt von einem Klein- oder Grobuchstaben "X" (0x oder 0X). Ein beliebiges Zeichen nach dem 0x, das auerhalb des Bereichs (0123456789ABCDEF) liegt, beendet die Literalsequenz.

0xFFFFFFFFFFFFF // 4503599627370495
0xabcdef123456  // 188900967593046
0XA             // 10

BigInt-Literal

Der BigInt Typ ist ein numerisches Primitive in JavaScript, das Ganzzahlen mit beliebiger Genauigkeit darstellen kann. BigInt-Literale werden erstellt, indem ein n an das Ende einer ganzen Zahl angehngt wird.

123456789123456789n     // 123456789123456789
0o777777777777n         // 68719476735
0x123456789ABCDEFn      // 81985529216486895
0b11101001010101010101n // 955733

BigInt-Literale knnen nicht mit 0 beginnen, um Verwechslungen mit veralteten Oktal-Literalen zu vermeiden.

0755n; // SyntaxError: invalid BigInt syntax

Fr oktale BigInt-Zahlen verwenden Sie immer eine Null, gefolgt vom Buchstaben "o" (gro oder klein):

0o755n;

Weitere Informationen zu BigInt, siehe auch JavaScript-Datenstrukturen.

Numerische Trenner

Um die Lesbarkeit von numerischen Literalen zu verbessern, knnen Unterstriche (_, U+005F) als Trenner verwendet werden:

1_000_000_000_000
1_050.95
0b1010_0001_1000_0101
0o2_2_5_6
0xA0_B0_C0
1_000_000_000_000_000_000_000n

Beachten Sie diese Einschrnkungen:

// More than one underscore in a row is not allowed
100__000; // SyntaxError

// Not allowed at the end of numeric literals
100_; // SyntaxError

// Can not be used after leading 0
0_1; // SyntaxError

String-Literale

Ein String-Literal ist null oder mehr Unicode-Codepunkte, die in einfache oder doppelte Anfhrungszeichen eingeschlossen sind. Unicode-Codepunkte knnen auch durch eine Escape-Sequenz dargestellt werden. Alle Codepunkte knnen in einem String-Literal wrtlich erscheinen, auer fr diese Codepunkte:

• U+005C \ (Backslash)
• U+000D <CR>
• U+000A <LF>
• Die gleiche Art von Anfhrungszeichen, die das String-Literal beginnt

Beliebige Codepunkte knnen in Form einer Escape-Sequenz erscheinen. String-Literale werden als ECMAScript-String-Werte ausgewertet. Beim Erzeugen dieser String-Werte werden Unicode-Codepunkte UTF-16-kodiert.

'foo'
"bar"

Die folgenden Unterabschnitte beschreiben verschiedene Escape-Sequenzen (\ gefolgt von einem oder mehreren Zeichen), die in String-Literalen verfgbar sind. Jede nicht unten aufgefhrte Escape-Sequenz wird zu einem "Identitts-Escape", der selbst der Codepunkt bleibt. Zum Beispiel ist \z dasselbe wie z. Es gibt eine veraltete Oktal-Escape-Sequenz-Syntax, die auf der Seite Veraltete und obsolet Funktionen beschrieben wird. Viele dieser Escape-Sequenzen sind auch in regulren Ausdrcken gltig siehe Zeichen-Escape.

Escape-Sequenzen

Spezialzeichen knnen mit Escape-Sequenzen kodiert werden:

Die letzte Escape-Sequenz, \ gefolgt von einem Zeilenabschluss, ist ntzlich, um ein String-Literal ber mehrere Zeilen zu teilen, ohne seine Bedeutung zu ndern.

const longString =
  "This is a very long string which needs \
to wrap across multiple lines because \
otherwise my code is unreadable.";

Achten Sie darauf, dass keine Leerzeichen oder andere Zeichen nach dem Backslash stehen (auer einem Zeilenumbruch), da es sonst nicht funktioniert. Wenn die nchste Zeile eingerckt ist, sind die zustzlichen Leerzeichen auch im Wert des Strings enthalten.

Sie knnen auch den +-Operator verwenden, um mehrere Strings aneinander zu hngen, wie folgt:

const longString =
  "This is a very long string which needs " +
  "to wrap across multiple lines because " +
  "otherwise my code is unreadable.";

Beide oben genannten Methoden ergeben identische Strings.

Hexadezimale Escape-Sequenzen

Hexadezimale Escape-Sequenzen bestehen aus \x, gefolgt von genau zwei hexadezimalen Ziffern, die eine Code-Einheit oder einen Codepunkt im Bereich von 0x0000 bis 0x00FF darstellen.

"\xA9"; // ""

Unicode-Escape-Sequenzen

Eine Unicode-Escape-Sequenz besteht aus genau vier hexadezimalen Ziffern, die \u folgen. Sie reprsentiert eine Codeeinheit in der UTF-16-Kodierung. Fr Codepunkte von U+0000 bis U+FFFF ist die Codeeinheit gleich dem Codepunkt. Codepunkte von U+10000 bis U+10FFFF erfordern zwei Escape-Sequenzen, die die beiden Codeeinheiten (ein Surrogatpaar) reprsentieren, die zur Kodierung des Zeichens verwendet werden; das Surrogatpaar unterscheidet sich vom Codepunkt.

Siehe auch String.fromCharCode() und String.prototype.charCodeAt().

"\u00A9"; // "" (U+A9)

Unicode-Codepunkt-Escapes

Ein Unicode-Codepunkt-Escape besteht aus \u{, gefolgt von einem Codepunkt in hexadezimaler Basis, gefolgt von }. Der Wert der hexadezimalen Ziffern muss im Bereich von 0 bis 0x10FFFF inklusive liegen. Codepunkte im Bereich von U+10000 bis U+10FFFF mssen nicht als Surrogatpaar dargestellt werden.

Siehe auch String.fromCodePoint() und String.prototype.codePointAt().

"\u{2F804}"; // CJK COMPATIBILITY IDEOGRAPH-2F804 (U+2F804)

// the same character represented as a surrogate pair
"\uD87E\uDC04";

Regulre Ausdrcke Literale

Regulre Ausdrcke-Literale sind von zwei Schrgstrichen (/) umgeben. Der Lexer konsumiert alle Zeichen bis zum nchsten nicht maskierten Schrgstrich oder dem Ende der Zeile, es sei denn, der Schrgstrich erscheint innerhalb einer Zeichenklasse ([]). Einige Zeichen (nmlich diejenigen, die Bezeichnerteile sind) knnen nach dem schlieenden Schrgstrich erscheinen und Flags anzeigen.

Die lexikalische Grammatik ist sehr grozgig: Nicht alle regulre Ausdrcke-Literale, die als ein Token identifiziert werden, sind gltige regulre Ausdrcke.

Siehe auch RegExp fr mehr Informationen.

/ab+c/g;
/[/]/;

Ein regulres Ausdrucksliteral kann nicht mit zwei Schrgstrichen (//) beginnen, da dies ein Zeilenkommentar wre. Um ein leeres regulres Ausdruck zu spezifizieren, verwenden Sie /(?:)/.

Template Literale

Ein Template Literal besteht aus mehreren Tokens: `xxx${ (Template Kopf), }xxx${ (Template Mitte) und }xxx` (Template Ende) sind einzelne Tokens, whrend jeder Ausdruck zwischen ihnen kommen kann.

Siehe auch Template Literale fr mehr Informationen.

`string text`;

`string text line 1
 string text line 2`;

`string text ${expression} string text`;

tag`string text ${expression} string text`;

Automatische Einfgung von Semikola

Einige JavaScript-Anweisungen' Syntaxdefinitionen erfordern Semikola (;) am Ende. Sie beinhalten:

• var, let, const, using, await using
• Ausdrucksanweisungen
• do...while
• continue, break, return, throw
• debugger
• Klassenfelddeklarationen (ffentlich oder privat)
• import, export

Um die Sprache jedoch zugnglicher und angenehmer zu machen, kann JavaScript Semikola automatisch einfgen, wenn es den Token-Stream konsumiert, sodass einige ungltige Token-Sequenzen zu einer gltigen Syntax "korrigiert" werden knnen. Dieser Schritt erfolgt, nachdem der Programmtext gem der lexikalischen Grammatik in Tokens geparst wurde. Es gibt drei Flle, in denen Semikola automatisch eingefgt werden:

1. Wenn ein Token, das nicht durch die Grammatik erlaubt ist, angetroffen wird und es durch mindestens einen Zeilenabschluss (ein blockweierter Kommentar, der mindestens einen Zeilenabschluss enthlt, eingeschlossen) vom vorherigen Token getrennt ist oder das Token "}" ist, wird ein Semikolon vor das Token eingefgt.

{ 1
2 } 3

// is transformed by ASI into:

{ 1
;2 ;} 3;

// Which is valid grammar encoding three statements,
// each consisting of a number literal

Das abschlieende ")" von do...while wird ebenfalls als Sonderfall durch diese Regel behandelt.

do {
  // 
} while (condition) /* ; */ // ASI here
const a = 1

Semikola werden jedoch nicht eingefgt, wenn das Semikolon dann der Trennzeichen im Kopf der for-Anweisung wird.

for (
  let a = 1 // No ASI here
  a < 10 // No ASI here
  a++
) {}

Semikola werden auch niemals als leere Anweisungen eingefgt. Zum Beispiel, im Code unten, wenn ein Semikolon nach ")" eingefgt wird, wrde der Code gltig sein, mit einer leeren Anweisung als if Body und der const Deklaration, die eine separate Anweisung ist. Da jedoch automatisch eingefgte Semikola keine leeren Anweisungen werden knnen, fhrt dies dazu, dass eine Deklaration der Body der if-Anweisung wird, was nicht gltig ist.

if (Math.random() > 0.5)
const x = 1 // SyntaxError: Unexpected token 'const'

2. Wenn das Ende des Eingabestreams von Tokens erreicht ist und der Parser den einfachen Eingabestream nicht als vollstndiges Programm parsen kann, wird ein Semikolon am Ende eingefgt.

const a = 1 /* ; */ // ASI here

Diese Regel ist ein Ergnzung zur vorherigen Regel, speziell fr den Fall, dass kein "strrisches Token" vorhanden ist, aber das Ende des Eingabestreams.

3. Wenn die Grammatik Zeilenabschlsse an einigen Stellen verbietet, aber ein Zeilenabschluss gefunden wird, wird ein Semikolon eingefgt. Diese Stellen schlieen ein:

• expr <here> ++, expr <here> --
• continue <here> lbl
• break <here> lbl
• return <here> expr
• throw <here> expr
• yield <here> expr
• yield <here> * expr
• (param) <here> => {}
• async <here> function, async <here> prop(), async <here> function*, async <here> *prop(), async <here> (param) <here> => {}
• using <here> id, await <here> using <here> id

Hier wird ++ nicht als Postfix-Operator behandelt, der auf die Variable b angewendet wird, da ein Zeilenabschluss zwischen b und ++ auftritt.

a = b
++c

// is transformed by ASI into

a = b;
++c;

Hier gibt die return-Anweisung undefined zurck, und das a + b wird zu einer unerreichbaren Anweisung.

return
a + b

// is transformed by ASI into

return;
a + b;

Beachten Sie, dass ASI (Automatische Semikolon-Einfgung) nur ausgelst wird, wenn ein Zeilenumbruch Tokens trennt, die sonst ungltige Syntax erzeugen wrden. Wenn das nchste Token als Teil einer gltigen Struktur geparst werden kann, werden Semikola nicht eingefgt. Ein Beispiel:

const a = 1
(1).toString()

const b = 1
[1, 2, 3].forEach(console.log)

Da () als Funktionsaufruf gesehen werden kann, wrde es ASI normalerweise nicht auslsen. In hnlicher Weise kann [] ein Memberzugriff sein. Der obige Code entspricht:

const a = 1(1).toString();

const b = 1[1, 2, 3].forEach(console.log);

Dies ist zufllig gltige Syntax. 1[1, 2, 3] ist ein Property-Accessor mit einem Komma-verbundenen Ausdruck. Daher wrden Sie beim Ausfhren des Codes Fehler wie "1 ist keine Funktion" und "Kann Eigenschaften von undefined nicht lesen (Lesen von 'forEach')" erhalten.

Innerhalb von Klassen knnen Klassenfelder und Generatormethoden ebenfalls Stolperfallen sein.

class A {
  a = 1
  *gen() {}
}

Es wird gesehen als:

class A {
  a = 1 * gen() {}
}

Und daher wird es ein Syntaxfehler um {.

Es gibt die folgenden Faustregeln im Umgang mit ASI, wenn Sie einen semikolonlosen Stil erzwingen mchten:

• Schreiben Sie Postfix ++ und -- in derselben Zeile wie ihre Operanden.

  js

  const a = b
  ++
  console.log(a) // ReferenceError: Invalid left-hand side expression in prefix operation
  

  js

  const a = b++
  console.log(a)
  

• Die Ausdrcke nach return, throw oder yield sollten in derselben Zeile wie das Schlsselwort sein.

  js

  function foo() {
    return
      1 + 1 // Returns undefined; 1 + 1 is ignored
  }
  

  js

  function foo() {
    return 1 + 1
  }
  
  function foo() {
    return (
      1 + 1
    )
  }
  

• In hnlicher Weise sollte der Bezeichner hinter dem Label nach break oder continue in derselben Zeile wie das Schlsselwort sein.

  js

  outerBlock: {
    innerBlock: {
      break
        outerBlock // SyntaxError: Illegal break statement
    }
  }
  

  js

  outerBlock: {
    innerBlock: {
      break outerBlock
    }
  }
  

• Das => einer Pfeilfunktion sollte in der gleichen Zeile wie das Ende seiner Parameter sein.

  js

  const foo = (a, b)
    => a + b
  

  js

  const foo = (a, b) =>
    a + b
  

• Das async von async Funktionen, Methoden, etc. kann nicht direkt von einem Zeilenabschluss gefolgt werden.

  js

  async
  function foo() {}
  

  js

  async function
  foo() {}
  

• Das using Schlsselwort in using und await using Anweisungen sollte in der gleichen Zeile wie der erste Bezeichner sein, den er deklariert.

  js

  using
  resource = acquireResource()
  

  js

  using resource
    = acquireResource()
  

• Wenn eine Zeile mit einer der folgenden beginnt: (, [, `, +, -, / (wie in Regex-Literalen), dann setzen Sie davor ein Semikolon oder enden Sie die vorherige Zeile mit einem Semikolon.

  js

  // The () may be merged with the previous line as a function call
  (() => {
    // 
  })()
  
  // The [ may be merged with the previous line as a property access
  [1, 2, 3].forEach(console.log)
  
  // The ` may be merged with the previous line as a tagged template literal
  `string text ${data}`.match(pattern).forEach(console.log)
  
  // The + may be merged with the previous line as a binary + expression
  +a.toString()
  
  // The - may be merged with the previous line as a binary - expression
  -a.toString()
  
  // The / may be merged with the previous line as a division expression
  /pattern/.exec(str).forEach(console.log)
  

  js

  ;(() => {
    // 
  })()
  ;[1, 2, 3].forEach(console.log)
  ;`string text ${data}`.match(pattern).forEach(console.log)
  ;+a.toString()
  ;-a.toString()
  ;/pattern/.exec(str).forEach(console.log)
  

• Klassenfelder sollten vorzugsweise immer mit Semikola beendet werden zustzlich zur vorherigen Regel (die eine Felddeklaration gefolgt von einem berechneten Eigentum einbezieht, da Letzteres mit [ beginnt), sind Semikola auch zwischen einer Felddeklaration und einer Generatormethode erforderlich.

  js

  class A {
    a = 1
    [b] = 2
    *gen() {} // Seen as a = 1[b] = 2 * gen() {}
  }
  

  js

  class A {
    a = 1;
    [b] = 2;
    *gen() {}
  }
  

Spezifikationen

Browser-Kompatibilitt

Siehe auch

• Grammatik und Typen Leitfaden
• Mikrofeature aus ES6, jetzt in Firefox Aurora und Nightly: binre und oktale Zahlen von Jeff Walden (2013)
• JavaScript-Zeichen-Escape-Sequenzen von Mathias Bynens (2011)