Re: "let" ausserhalb eines Blocks

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:
> Im Web habe ich folgendes gelesen:
>
> |The difference between var and let becomes significant when
> |you're declaring them in blocks

„Im Web“ – wann lernst Du endlich, Deine Quellen korrekt anzugeben …

> .

… und korrekte Interpunktion zu verwenden?

> Tatsächlich wird in Lehrtexten zu "let" und "var" oft
> deren Unterschied /innerhalb/ eines Blocks behandelt.
>
> Daher ist es nicht ganz einfach, begründete Richtlinien
> für die Verwendung außerhalb von Blöcken zu finden.
>
> Auch außerhalb von Blöcken kann man ja "var" oder "let"
> verwenden.
>
> Nehmen wir einmal an, aus irgendeinem Grund soll einem Namen
> /außerhalb/ eines Blocks (und auch außerhalb einer Funktion
> oder einer Klasse) ein bestimmter Wert gegeben werden.
>
> Wann ist es dann besser "let" dafür zu verwenden und wann
> "var"? (und warum?)

Kompatibilität oder Transpiler (z. B. Babel <https://babeljs.io/>)
vorausgesetzt, ist es in produktivem Code immer besser, “let” oder “const”
statt “var” zu verwenden, denn:

- der Gültigkeitsbereich einer Variablen wird auf einen lexikalischen
Kontext, unabhängig vom Ausführungskontext, begrenzt (z. B. auf Block
Anweisungen);

- Mehrfachdeklarationen in einem lexikalischen Kontext sind
definitionsgemäss nicht möglich, Deklarationen mit gleichen Bezeichnern
in unterschiedlichen lexikalischen Kontexten aber schon (vermeidet
Nebeneffekte);

- mit “const” kann deklariert werden, dass einer Variable nur einmalig
ein Wert zugewiesen werden kann.

Linter (Werkzeuge zur Sicherstellung der Quelltextqualität) wie ESLint
(ziehe ich inzwischen (JSHint, und jslint sowieso, vor) können dann den
Entwickler schon beim Schreiben im Editor darauf aufmerksam machen, wenn das
Programm *logisch* fehlerhaft ist, und es kann mit geeigneten Regeln sogar
verhindert werden, dass logisch fehlerhafter Code deployed wird:

<https://eslint.org/>
<https://atom.io/packages/linter-eslint>

Airbnb stellt dazu den Airbnb JavaScript Style Guide bereit, in dem auch
Konfigurationsoptionen für ESLint referenziert werden, die die Einhaltung
der jeweiligen Stilempfehlung unterstützen oder erzwingen:

<https://github.com/airbnb/javascript>

Ich bin zwar nicht mit allen Empfehlungen darin einverstandem (die werden
auch laufend angepasst; bei Referenzen sollte also die Abschnittsnummer und
die Kurzfassung der Regel angegeben werden), er ist aber eine sehr gute
Grundlage.

Die entsprechende Empfehlung zu “const” bzw. “let” darin ist eine der ersten:

<https://github.com/airbnb/javascript#references>

Siehe auch die Begründungen dort.

Von Nachteil ist die Verwendung von “let” oder “const” beim Ausprobieren von
Code in der Script-Konsole in modernen Web-Browsern, weil das Ausprobieren
von leicht verändertem Code damit erschwert wird. Eine deklarierte globale
"Konstante" kann beispielsweise naturgemäss nicht anders definiert werden,
aber auch nicht "undeklariert" werden, so dass dann der Tab neu geladen
werden muss, wenn sie anders definiert werden soll; umgehen lässt sich das
durch einen unmittelbar ausgeführten Funktionsausdruck (IIFE – Immediately
Invoked Function Expression) – (function () { … }()) – und die Deklaration
der "Konstanten" in der Funktion, aber das erfordert auch zusätzlichen
Schreibaufwand.

--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
> Kompatibilität oder Transpiler (z. B. Babel <https://babeljs.io/>)
> vorausgesetzt, ist es in produktivem Code immer besser, “let” oder “const”
> statt “var” zu verwenden, denn:
>
> - der Gültigkeitsbereich einer Variablen wird auf einen lexikalischen
> Kontext, unabhängig vom Ausführungskontext, begrenzt (z. B. auf Block
> Anweisungen);
>
> - Mehrfachdeklarationen in einem lexikalischen Kontext sind
> definitionsgemäss nicht möglich, Deklarationen mit gleichen Bezeichnern
> in unterschiedlichen lexikalischen Kontexten aber schon (vermeidet
> Nebeneffekte);

Wichtig: Die Deklaration bezogen auf einen lexikalischen Kontext hat auch
zur Folge, dass Referenzen auf eine Variable nicht zulässig sind, bevor die
Variable im Quelltext deklariert wurde. Dies gilt auch, wenn die Referenz
das Argument des typeof-Operators ist:

/* undefined */
typeof x;

var x;

aber:

/* ReferenceError: x is not defined */
typeof x;

let x;

Dies kann man als Nachteil von “const” und “let” gegenüber “var” betrachten,
es führt aber zu weniger fehlerträchtigem Code. (Es führt auch zu einem
Codestil, den ich schon immer praktiziere und empfohlen habe: man deklariere
die Variablen dort, wo man sie zuerst braucht, und NICHT irgendwo – weder
ganz unten noch ganz oben – im Code.)

IMHO sollte es den Feature-Test, der mit dem typeof-Operator
abwärtskompatibel möglich ist, nicht beeinflussen, da es sich bei Features
um Eigenschaften und nicht um Variablen handelt. Bestehender Test-Code muss
aber sorgfältig überprüft werden und sollte besser nicht im globalen Kontext
ausgeführt werden (weil der dazugehörige lexikalische Kontext naturgemäss
weniger gut bekannt ist).

<http://es-discourse.com/t/why-typeof-is-no-longer-safe/15>