Lexikalische Grammatik

Formatsteuerzeichen

Formatsteuerzeichen haben keine sichtbare Darstellung, dienen aber dazu, die Interpretation des Textes zu steuern.

Im JavaScript-Quelltext werden <ZWNJ> und <ZWJ> als Bestandteile von Bezeichnern behandelt. <BOM> wird dagegen als Leerraumzeichen behandelt; wenn es nicht am Textanfang steht, heit es auch Zero-Width No-Break Space (<ZWNBSP>).

Leerraumzeichen

Leerraumzeichen verbessern die Lesbarkeit des Quelltexts und trennen Tokens voneinander. Fr die Funktion des Codes sind sie normalerweise nicht erforderlich. Hufig werden Minifizierungswerkzeuge eingesetzt, um Leerraumzeichen zu entfernen und so die zu bertragende Datenmenge zu verringern.

Zeilenabschlusszeichen

Neben Leerraumzeichen verbessern auch Zeilenabschlusszeichen die Lesbarkeit des Quelltexts. In manchen Fllen knnen Zeilenabschlusszeichen jedoch die Ausfhrung von JavaScript-Code beeinflussen, da sie an einigen Stellen nicht zulssig sind. Sie wirken sich auerdem auf die automatische Semikolon-Einfgung aus.

Auerhalb der lexikalischen Grammatik werden Leerraumzeichen und Zeilenabschlusszeichen hufig zusammengefasst. Beispielsweise entfernt String.prototype.trim() alle Leerraum- und Zeilenabschlusszeichen am Anfang und Ende einer Zeichenfolge. Die \s-Zeichenklassen-Escape-Sequenz in regulren Ausdrcken erfasst smtliche Leerraum- und Zeilenabschlusszeichen.

In ECMAScript werden nur die folgenden Unicode-Codepunkte als Zeilenabschlusszeichen behandelt. Andere Zeichen fr Zeilenumbrche werden als Leerraumzeichen behandelt (beispielsweise gilt Next Line, NEL, U+0085 als Leerraumzeichen).

Kommentare

Mit Kommentaren knnen Sie JavaScript-Code um Hinweise, Anmerkungen, Vorschlge oder Warnungen ergnzen. Dadurch lsst sich der Code leichter lesen und verstehen. Kommentare knnen auch Code deaktivieren und so dessen Ausfhrung verhindern ein ntzliches Werkzeug bei der Fehlersuche.

In JavaScript gibt es seit Langem zwei Mglichkeiten, Code zu kommentieren: Zeilenkommentare und Blockkommentare. Darber hinaus gibt es eine spezielle Syntax fr Hashbang-Kommentare.

Zeilenkommentare

Die erste Mglichkeit ist der Kommentar mit //. Der gesamte darauf folgende Text derselben Zeile wird dadurch zum Kommentar. Zum Beispiel:

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

Blockkommentare

Die zweite Mglichkeit ist die deutlich flexiblere Schreibweise /* */.

Sie knnen sie beispielsweise in einer einzelnen Zeile verwenden:

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

Sie knnen damit auch mehrzeilige Kommentare erstellen:

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();

Ebenso knnen Sie sie mitten in einer Zeile verwenden. Da der Code dadurch schwerer lesbar werden kann, sollten Sie diese Mglichkeit jedoch mit Bedacht einsetzen:

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

Auerdem knnen Sie Code deaktivieren, indem Sie ihn in einen Kommentar einschlieen:

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

In diesem Fall wird console.log() nie aufgerufen, da der Aufruf innerhalb eines Kommentars steht. Auf diese Weise lassen sich beliebig viele Codezeilen deaktivieren.

Blockkommentare, die mindestens ein Zeilenabschlusszeichen enthalten, verhalten sich bei der automatischen Semikolon-Einfgung wie Zeilenabschlusszeichen.

Hashbang-Kommentare

Es gibt eine spezielle dritte Kommentarsyntax: den Hashbang-Kommentar. Ein Hashbang-Kommentar verhlt sich genau wie ein einzeiliger Kommentar mit //, beginnt aber mit #! und ist nur unmittelbar am Anfang eines Skripts oder Moduls gltig. Vor #! darf keinerlei Leerraum stehen. Der Kommentar umfasst alle Zeichen nach #! bis zum Ende der ersten Zeile; nur ein solcher Kommentar ist zulssig.

Hashbang-Kommentare in JavaScript hneln Shebangs unter Unix. Diese geben den Pfad zu einem bestimmten JavaScript-Interpreter an, mit dem das Skript ausgefhrt werden soll. Bevor Hashbang-Kommentare standardisiert wurden, waren sie in Umgebungen auerhalb des Browsers wie Node.js bereits de facto implementiert. Dort wurden sie aus dem Quelltext entfernt, bevor dieser an die Engine bergeben wurde. Ein Beispiel:

#!/usr/bin/env node

console.log("Hello world");

Der JavaScript-Interpreter behandelt den Hashbang als normalen Kommentar. Nur fr die Shell hat er eine besondere Bedeutung, wenn das Skript direkt in einer Shell ausgefhrt wird.

Verwenden Sie die Kommentarschreibweise #! ausschlielich, um einen JavaScript-Interpreter anzugeben. Verwenden Sie in allen anderen Fllen einen Kommentar mit // oder einen mehrzeiligen Kommentar.

Bezeichner

Ein Bezeichner verknpft einen Wert mit einem Namen. 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 hufig aus alphanumerischen Zeichen, Unterstrichen (_) und Dollarzeichen ($). Sie drfen nicht mit einer Ziffer beginnen. JavaScript-Bezeichner sind jedoch nicht auf ASCII beschrnkt auch viele Unicode-Codepunkte sind zulssig. Genauer gesagt:

• Als erstes Zeichen sind alle Zeichen der Kategorie ID_Start sowie _ und $ zulssig.
• Nach dem ersten Zeichen knnen Sie alle Zeichen der Kategorie ID_Continue verwenden. Dazu gehren U+200C (ZWNJ) und U+200D (ZWJ).

Darber hinaus erlaubt JavaScript in Bezeichnern Unicode-Escape-Sequenzen der Form \u0000 oder \u{000000}. Sie kodieren denselben Zeichenfolgenwert wie die entsprechenden Unicode-Zeichen. Beispielsweise sind und \u4f60\u597d derselbe Bezeichner:

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

Nicht berall ist der gesamte Bereich zulssiger Bezeichner erlaubt. Bestimmte Syntaxformen, etwa Funktionsdeklarationen, Funktionsausdrcke und Variablendeklarationen, erfordern Bezeichnernamen, die keine reservierten Wrter sind.

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

Insbesondere bei privaten Elementen und Objekteigenschaften sind reservierte Wrter zulssig.

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

Schlsselwrter

Schlsselwrter sind Tokens, die wie Bezeichner aussehen, in JavaScript aber eine besondere Bedeutung haben. Beispielsweise zeigt das Schlsselwort async vor einer Funktionsdeklaration an, dass die Funktion asynchron ist.

Einige Schlsselwrter sind reserviert. Das bedeutet, dass sie beispielsweise in Variablen- oder Funktionsdeklarationen nicht als Bezeichner verwendet werden knnen. Sie werden hufig reservierte Wrter genannt. Eine Liste dieser reservierten Wrter finden Sie weiter unten. Nicht alle Schlsselwrter sind reserviert: async kann beispielsweise berall als Bezeichner verwendet werden. Andere Schlsselwrter sind nur kontextabhngig reserviert: await ist beispielsweise nur im Rumpf einer asynchronen Funktion reserviert, whrend let nur in Code im Strict Mode oder in const- und let-Deklarationen reserviert ist.

Bezeichner werden stets anhand ihres Zeichenfolgenwerts verglichen. Escape-Sequenzen werden daher interpretiert. Beispielsweise liegt hier weiterhin ein Syntaxfehler vor:

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

Reservierte Wrter

Diese Schlsselwrter knnen nirgendwo im 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 Wrter sind nur in Code im Strict Mode reserviert:

• let (auch in const-, let- und Klassendeklarationen reserviert)
• static
• yield (auch im Rumpf von Generatorfunktionen reserviert)

Das folgende Wort ist nur in Modulcode oder im Rumpf asynchroner Funktionen reserviert:

• await

Fr die Zukunft reservierte Wrter

Die folgenden Wrter sind in der ECMAScript-Spezifikation als knftige Schlsselwrter reserviert. Derzeit haben sie keine besondere Funktion, knnten aber knftig eine erhalten. Deshalb knnen sie nicht als Bezeichner verwendet werden.

Dieses Wort ist immer reserviert:

• enum

Die folgenden Wrter sind nur in Code im Strict Mode reserviert:

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

In lteren Standards fr die Zukunft reservierte Wrter

Die folgenden Wrter waren in lteren ECMAScript-Spezifikationen (ECMAScript 1 bis 3) als knftige Schlsselwrter reserviert.

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

Bezeichner mit besonderer Bedeutung

Einige Bezeichner haben in bestimmten Kontexten eine besondere Bedeutung, ohne reservierte Wrter zu sein. Dazu gehren:

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

Literale

Null-Literal

Weitere Informationen finden Sie auch unter null.

null

Boolean-Literal

Weitere Informationen finden Sie auch unter Boolean-Typ.

true
false

Numerische Literale

Die Typen Number und BigInt verwenden numerische Literale.

Dezimal

1234567890
42

Dezimale Literale knnen mit einer Null (0) beginnen, auf die eine weitere Dezimalziffer folgt. Sind jedoch alle Ziffern nach der fhrenden 0 kleiner als 8, wird die Zahl als Oktalzahl interpretiert. Diese Syntax gilt als veraltet. Zahlenliterale mit vorangestellter 0 verursachen im Strict Mode einen Syntaxfehler unabhngig davon, ob sie als Oktal- oder Dezimalzahl interpretiert wrden. Verwenden Sie stattdessen das Prfix 0o.

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

Exponentialschreibweise

Ein dezimales Exponentialliteral hat das Format beN. Dabei ist b eine Basiszahl (Ganzzahl oder Gleitkommazahl), gefolgt von E oder e als Trennzeichen beziehungsweise Exponentenkennzeichen. N ist der Exponent eine vorzeichenbehaftete Ganzzahl.

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

Binr

Die Syntax fr Binrzahlen beginnt mit einer Null, gefolgt vom lateinischen Buchstaben B in Klein- oder Groschreibung (0b oder 0B). Jedes Zeichen nach 0b, das weder 0 noch 1 ist, beendet die Literalsequenz.

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

Oktal

Die Syntax fr Oktalzahlen beginnt mit einer Null, gefolgt vom lateinischen Buchstaben O in Klein- oder Groschreibung (0o oder 0O). Jedes Zeichen nach 0o, das auerhalb des Bereichs (01234567) liegt, beendet die Literalsequenz.

0O755 // 493
0o644 // 420

Hexadezimal

Die Syntax fr Hexadezimalzahlen beginnt mit einer Null, gefolgt vom lateinischen Buchstaben X in Klein- oder Groschreibung (0x oder 0X). Jedes Zeichen nach 0x, das auerhalb des Bereichs (0123456789ABCDEF) liegt, beendet die Literalsequenz.

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

BigInt-Literal

Der Typ BigInt ist ein numerischer primitiver Typ in JavaScript, der Ganzzahlen mit beliebiger Genauigkeit darstellen kann. BigInt-Literale werden gebildet, indem an eine Ganzzahl ein n angehngt wird.

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

BigInt-Literale drfen nicht mit 0 beginnen, um Verwechslungen mit veralteten Oktalliteralen zu vermeiden.

0755n; // SyntaxError: invalid BigInt syntax

Verwenden Sie fr oktale BigInt-Zahlen immer eine Null, gefolgt vom Buchstaben o (gro- oder kleingeschrieben):

0o755n;

Weitere Informationen zu BigInt finden Sie unter JavaScript-Datenstrukturen.

Numerische Trennzeichen

Um numerische Literale besser lesbar zu machen, knnen Unterstriche (_, U+005F) als Trennzeichen 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 dabei folgende 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

Zeichenfolgenliterale

Ein Zeichenfolgenliteral besteht aus null oder mehr Unicode-Codepunkten, die in einfache oder doppelte Anfhrungszeichen eingeschlossen sind. Unicode-Codepunkte knnen auch durch Escape-Sequenzen dargestellt werden. Alle Codepunkte drfen direkt in einem Zeichenfolgenliteral vorkommen, mit Ausnahme der folgenden:

• U+005C \ (umgekehrter Schrgstrich)
• U+000D <CR>
• U+000A <LF>
• Anfhrungszeichen derselben Art, mit der das Zeichenfolgenliteral beginnt

Jeder Codepunkt kann in Form einer Escape-Sequenz vorkommen. Zeichenfolgenliterale ergeben ECMAScript-String-Werte. Bei der Erzeugung dieser String-Werte werden Unicode-Codepunkte in UTF-16 kodiert.

'foo'
"bar"

Die folgenden Unterabschnitte beschreiben verschiedene Escape-Sequenzen (ein \, gefolgt von einem oder mehreren Zeichen), die in Zeichenfolgenliteralen verfgbar sind. Jede unten nicht aufgefhrte Escape-Sequenz wird zu einem Identity Escape, der dem Codepunkt des Zeichens selbst entspricht. Beispielsweise ist \z dasselbe wie z. Eine veraltete Syntax fr oktale Escape-Sequenzen wird auf der Seite Veraltete und obsolete Funktionen beschrieben. Viele dieser Escape-Sequenzen sind auch in regulren Ausdrcken gltig siehe Zeichen-Escape.

Escape-Sequenzen

Sonderzeichen knnen mit Escape-Sequenzen kodiert werden:

Die letzte Escape-Sequenz ein \, gefolgt von einem Zeilenabschlusszeichen ist ntzlich, um ein Zeichenfolgenliteral ber mehrere Zeilen zu verteilen, 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.";

Stellen Sie sicher, dass nach dem umgekehrten Schrgstrich kein Leerzeichen oder anderes Zeichen steht (auer einem Zeilenumbruch). Andernfalls funktioniert dies nicht. Wenn die nchste Zeile eingerckt ist, sind die zustzlichen Leerzeichen auch im Wert der Zeichenfolge enthalten.

Sie knnen auch den Operator + verwenden, um mehrere Zeichenfolgen aneinanderzuhngen:

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

Beide beschriebenen Methoden ergeben identische Zeichenfolgen.

Hexadezimale Escape-Sequenzen

Hexadezimale Escape-Sequenzen bestehen aus \x, gefolgt von genau zwei hexadezimalen Ziffern. Diese stellen eine Codeeinheit oder einen Codepunkt im Bereich von 0x0000 bis 0x00FF dar.

"\xA9"; // ""

Unicode-Escape-Sequenzen

Eine Unicode-Escape-Sequenz besteht aus genau vier hexadezimalen Ziffern nach \u. Sie stellt eine Codeeinheit in der UTF-16-Kodierung dar. Bei Codepunkten von U+0000 bis U+FFFF entspricht die Codeeinheit dem Codepunkt. Codepunkte von U+10000 bis U+10FFFF bentigen zwei Escape-Sequenzen, die die beiden zur Kodierung des Zeichens verwendeten Codeeinheiten darstellen (ein Surrogatpaar). Das Surrogatpaar ist nicht mit dem Codepunkt identisch.

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

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

Unicode-Codepunkt-Escape-Sequenzen

Eine Unicode-Codepunkt-Escape-Sequenz besteht aus \u{, gefolgt von einem hexadezimal angegebenen Codepunkt und }. Der Wert der hexadezimalen Ziffern muss einschlielich der Grenzen zwischen 0 und 0x10FFFF liegen. Codepunkte im Bereich 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";

Literale regulrer Ausdrcke

Literale regulrer Ausdrcke werden von zwei Schrgstrichen (/) eingeschlossen. Der Lexer liest alle Zeichen bis zum nchsten nicht mit einer Escape-Sequenz versehenen Schrgstrich oder bis zum Zeilenende, es sei denn, der Schrgstrich steht innerhalb einer Zeichenklasse ([]). Nach dem abschlieenden Schrgstrich knnen bestimmte Zeichen stehen (nmlich solche, die Bestandteile von Bezeichnern sein knnen); sie kennzeichnen Flags.

Die lexikalische Grammatik ist sehr nachsichtig: Nicht jedes Literal eines regulren Ausdrucks, das als einzelnes Token erkannt wird, ist ein gltiger regulrer Ausdruck.

Weitere Informationen finden Sie auch unter RegExp.

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

Ein Literal eines regulren Ausdrucks kann nicht mit zwei Schrgstrichen (//) beginnen, da dies einen Zeilenkommentar einleiten wrde. Verwenden Sie /(?:)/, um einen leeren regulren Ausdruck anzugeben.

Template-Literale

Ein Template-Literal besteht aus mehreren Tokens: `xxx${ (Template-Anfang), }xxx${ (Template-Mittelteil) und }xxx` (Template-Ende) sind jeweils eigenstndige Tokens. Dazwischen kann ein beliebiger Ausdruck stehen.

Weitere Informationen finden Sie auch unter Template-Literale.

`string text`;

`string text line 1
 string text line 2`;

`string text ${expression} string text`;

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

Automatische Semikolon-Einfgung

Die Syntaxdefinitionen einiger JavaScript-Anweisungen verlangen ein Semikolon (;) am Ende. Dazu gehren:

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

Um die Sprache zugnglicher und komfortabler zu machen, kann JavaScript beim Verarbeiten des Tokenstroms automatisch Semikolons einfgen. Dadurch knnen einige ungltige Tokenfolgen zu gltiger Syntax korrigiert werden. Dieser Schritt erfolgt, nachdem der Programmtext gem der lexikalischen Grammatik in Tokens zerlegt wurde. In drei Fllen werden Semikolons automatisch eingefgt:

1. Wenn ein Token auftritt, das die Grammatik nicht zulsst, und es vom vorherigen Token durch mindestens ein Zeilenabschlusszeichen getrennt ist (einschlielich eines Blockkommentars mit mindestens einem Zeilenabschlusszeichen), oder wenn das Token } ist, wird vor dem Token ein Semikolon 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

Die schlieende Klammer ) von do...while wird durch diese Regel ebenfalls als Sonderfall behandelt.

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

Es werden jedoch keine Semikolons eingefgt, wenn das Semikolon dadurch zum Trennzeichen im Kopf einer for-Anweisung wrde.

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

Automatisch eingefgte Semikolons bilden auch niemals leere Anweisungen. Im folgenden Code wre beispielsweise ein Semikolon nach ) gltig: Der Rumpf der if-Anweisung wre dann eine leere Anweisung, und die const-Deklaration wre eine separate Anweisung. Da automatisch eingefgte Semikolons jedoch keine leeren Anweisungen bilden drfen, wrde die Deklaration zum Rumpf der if-Anweisung. Das ist ungltig.

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

2. Wenn das Ende des Tokenstroms erreicht ist und der Parser den Tokenstrom nicht als vollstndiges Programm parsen kann, wird am Ende ein Semikolon eingefgt.

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

Diese Regel ergnzt die vorherige fr den Fall, dass kein unzulssiges Token vorhanden ist, sondern lediglich das Ende des Eingabestroms erreicht wurde.

3. Wenn die Grammatik an einer bestimmten Stelle Zeilenabschlusszeichen verbietet, dort aber eines vorkommt, wird ein Semikolon eingefgt. Zu diesen Stellen gehren:

• 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 fr die Variable b behandelt, weil zwischen b und ++ ein Zeilenabschlusszeichen steht.

a = b
++c

// is transformed by ASI into

a = b;
++c;

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

return
a + b

// is transformed by ASI into

return;
a + b;

Beachten Sie, dass die automatische Semikolon-Einfgung (ASI) nur ausgelst wird, wenn ein Zeilenumbruch Tokens trennt, die andernfalls ungltige Syntax ergeben wrden. Kann das nchste Token als Teil einer gltigen Struktur geparst werden, wird kein Semikolon eingefgt. Zum Beispiel:

const a = 1
(1).toString()

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

Da () als Funktionsaufruf interpretiert werden kann, lst es normalerweise keine automatische Semikolon-Einfgung aus. Ebenso kann [] ein Eigenschaftszugriff sein. Der obige Code entspricht:

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

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

Das ist zufllig gltige Syntax. 1[1, 2, 3] ist ein Eigenschaftszugriff mit einem durch Kommas verknpften Ausdruck. Beim Ausfhren des Codes erhalten Sie daher Fehlermeldungen wie 1 is not a function und Cannot read properties of undefined (reading 'forEach').

Innerhalb von Klassen knnen auch Klassenfelder und Generatormethoden eine Fehlerquelle sein.

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

Der Code wird wie folgt interpretiert:

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

Daher tritt bei { ein Syntaxfehler auf.

Wenn Sie einen Stil ohne Semikolons durchsetzen mchten, helfen Ihnen die folgenden Faustregeln beim Umgang mit ASI:

• Schreiben Sie die Postfix-Operatoren ++ und -- in dieselbe 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)
  

• Der Ausdruck nach return, throw oder yield sollte in derselben Zeile wie das Schlsselwort stehen.

  js

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

  js

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

• Ebenso sollte der Label-Bezeichner nach break oder continue in derselben Zeile wie das Schlsselwort stehen.

  js

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

  js

  outerBlock: {
    innerBlock: {
      break outerBlock
    }
  }
  

• Das => einer Pfeilfunktion sollte in derselben Zeile stehen wie das Ende ihrer Parameterliste.

  js

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

  js

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

• Auf async bei asynchronen Funktionen, Methoden usw. darf nicht unmittelbar ein Zeilenabschlusszeichen folgen.

  js

  async
  function foo() {}
  

  js

  async function
  foo() {}
  

• Das Schlsselwort using in using- und await using-Anweisungen sollte in derselben Zeile stehen wie der erste damit deklarierte Bezeichner.

  js

  using
  resource = acquireResource()
  

  js

  using resource
    = acquireResource()
  

• Wenn eine Zeile mit (, [, `, +, - oder / (wie bei Literalen regulrer Ausdrcke) beginnt, stellen Sie ihr ein Semikolon voran oder beenden 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 einem Semikolon abgeschlossen werden. Zustzlich zur vorherigen Regel (die auch eine Felddeklaration vor einer berechneten Eigenschaft umfasst, da Letztere mit [ beginnt) sind Semikolons 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

• Leitfaden Grammatik und Typen
• Kleine Neuerung aus ES6, jetzt in Firefox Aurora und Nightly: Binr- und Oktalzahlen von Jeff Walden (2013)
• JavaScript-Zeichen-Escape-Sequenzen von Mathias Bynens (2011)