Path: csiph.com!news.mixmin.net!news2.arglkargh.de!news.karotte.org!news.space.net!news.m-online.net!news.bgeserver.de!bgepartei.de!news2.open-news-network.org!.POSTED.16.235.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: de.comp.lang.javascript Subject: Re: "let" ausserhalb eines Blocks Date: Mon, 22 Apr 2019 22:22:53 +0200 Organization: PointedEars Software (PES) Message-ID: <4bc5fbc8-993a-9b04-9e21-1c60aec65d1a@PointedEars.de> References: Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: news2.open-news-network.org; posting-host="16.235.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch:178.197.235.16"; logging-data="25730"; mail-complaints-to="abuse@bgeserver.de" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 In-Reply-To: Content-Language: de-CH Xref: csiph.com de.comp.lang.javascript:5042 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 ) 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: 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: 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: 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.