JavaScript Tutorial Variablendeklarationen

[Matthias Wallnöfer]

Liebe Autoren des JavaScript-Tutorials,

wäre es inzwischen nicht zeitgemäß, bei Variablendeklarationen auf die erneuerten Schlüsselwörter let und const zurückzugreifen, die bereits seit geraumer Zeit in allen gängigen Browsern Unterstützung finden?

var würde ich höchstens noch in einem kurzen Absatz erwähnen, dass das mal der Standard war. In neuem Code sollte das Schlüsselwort möglichst vermieden werden, um mit dem Verhalten anderer Programmiersprachen gleichzuziehen.

Daher schlage ich vor, alle Codebeispiele dementsprechend anzupassen. Sehr gut gefällt mir die Erwähnung des strict-Modus welcher hilft, Anfänger wirksam vor der Falle ungewollten Verhaltens zu verschonen.

[Matthias Scharwies]

Servus!

Liebe Autoren des JavaScript-Tutorials,

wäre es inzwischen nicht zeitgemäß, bei Variablendeklarationen auf die erneuerten Schlüsselwörter let und const zurückzugreifen, die bereits seit geraumer Zeit in allen gängigen Browsern Unterstützung finden?

Gute Idee,

Es ist ein Wiki, d.h. Du selbst kannst entsprechende Änderungen selbst vornehmen! Am besten, aber nicht erforderlich, wäre eine Anmeldung im Wiki. Nur für eine Änderung der Live-Beipiele muss man Beispiel-Administrator sein.

var würde ich höchstens noch in einem kurzen Absatz erwähnen, dass das mal der Standard war. In neuem Code sollte das Schlüsselwort möglichst vermieden werden, um mit dem Verhalten anderer Programmiersprachen gleichzuziehen.

Ja!

Daher schlage ich vor, alle Codebeispiele dementsprechend anzupassen. Sehr gut gefällt mir die Erwähnung des strict-Modus welcher hilft, Anfänger wirksam vor der Falle ungewollten Verhaltens zu verschonen.

Danke!

Herzliche Grüße

Matthias Scharwies

[Matthias Apsel]

Hallo Matthias Wallnöfer,

wäre es inzwischen nicht zeitgemäß, bei Variablendeklarationen auf die erneuerten Schlüsselwörter let und const zurückzugreifen, die bereits seit geraumer Zeit in allen gängigen Browsern Unterstützung finden?

Unbedingt. Magst du uns unterstützen?

var würde ich höchstens noch in einem kurzen Absatz erwähnen, dass das mal der Standard war. In neuem Code sollte das Schlüsselwort möglichst vermieden werden, um mit dem Verhalten anderer Programmiersprachen gleichzuziehen.

Unbedingt!

Daher schlage ich vor, alle Codebeispiele dementsprechend anzupassen. Sehr gut gefällt mir die Erwähnung des strict-Modus welcher hilft, Anfänger wirksam vor der Falle ungewollten Verhaltens zu verschonen.

Unbedingt!!

Richtig cool wäre auch eine Übersichtsseite, die die Einsatzgebiete und Unterschiede zwischen let, const (und var) darstellt.

Bis demnächst
Matthias

[Matthias Scharwies]

Servus!

Richtig cool wäre auch eine Übersichtsseite, die die Einsatzgebiete und Unterschiede zwischen let, const (und var) darstellt.

Das wäre wohl: JavaScript/Variable

Auf die wird in JavaScript/Tutorials/Einstieg/Erste_Schritte schon verlinkt.

Herzliche Grüße

Matthias Scharwies

[Matthias Apsel]

Hallo Matthias Scharwies,

wusst ichs doch, dass es a) sowas schon gibt und b) du auch sofort weißt, wo es zu finden ist.

„Du fragst – Matthias antwortet“ (insider)

Bis demnächst
Matthias

[Matthias Scharwies]

Servus!

„Du fragst – Matthias antwortet“ (insider)

Das waren jetzt 3 Matthiasse in diesem Fred - meine Mutter nannte mich so, weil der Name so selten war. Auf dem Spielplatz unserer Trabantenstadt waren wir dann 4 Namensvettern.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

schon, aber da wird let/const nur nebenbei erwähnt. Der Text bleibt bei var. Orlok hat zwei ausführliche Artikel zu let und const geschrieben, die im Variablen-Artikel verlinkt sind - ich bin aber der Meinung, dass man da nochmal ran muss. Da ist viel zu viel Redundanz drin, weil die Artikel so geschrieben sind, als wüsste der eine nichts vom anderen.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

JavaScript/Variable

schon, aber da wird let/const nur nebenbei erwähnt. Der Text bleibt bei var. Orlok hat zwei ausführliche Artikel zu let und const geschrieben, die im Variablen-Artikel verlinkt sind - ich bin aber der Meinung, dass man da nochmal ran muss. Da ist viel zu viel Redundanz drin, weil die Artikel so geschrieben sind, als wüsste der eine nichts vom anderen.

Ja, ich mach mich grad drüber.

BTW: Würdet ihr const-Variablen in CAPITAL LETTERS schreiben oder wie die MDN in normaler Kleinschreibung?

Herzliche Grüße

Matthias Scharwies

[JürgenB]

Hallo Matthias,

ich würde const klein schreiben.

Gruß
Jürgen

[Gunnar Bittersmann]

@@Matthias Scharwies

BTW: Würdet ihr const-Variablen in CAPITAL LETTERS schreiben oder wie die MDN in normaler Kleinschreibung?

I.d.R. klein. Weil das, was in JavaScript const ist, über das hinausgeht, was Konstanten in anderen Sprachen (PHP) sind.

So sind bei mir sämtliche Referenzen auf DOM-Elemente const:

const detailsElement = document.querySelector('details');

Eigenschaften dieser Objekte sind nicht unbedingt konstant, sondern können geändert werden:

detailsElement.open = true;

Oder wie im jüngsten Mathe-Rätsel:

const calendarium = [29, 30, 31];

Das Array wird danach aber noch erweitert:

for (let monthLength of monthLengthsInYear) {
	for (let i = 1; i <= monthLength; i++) {
		calendarium.push(i);
	}
}

Großschreiben würde ich echte Konstanten wie z.B.

const PHI = (1 + Math.sqrt(5))/2;

Das aber eher ins Math-Objekt hinein:

Math.SQRT5 = Math.sqrt(5);
Math.PHI = (1 + Math.SQRT5)/2;

😷 LLAP

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

Danke, Das Referenzen auf DOM-Elemente klau' ich mir!

Herzliche Grüße

Matthias Scharwies

[dedlfix]

Tach!

BTW: Würdet ihr const-Variablen in CAPITAL LETTERS schreiben oder wie die MDN in normaler Kleinschreibung?

Es gibt - wohl vor allem wegen der damaligen Entwicklungsumgebungen mit ihren eingeschränkten Möglichkeiten - seit langem die Konvention, Konstanten in Großbuchstaben zu schreiben. Das ist heutzutage nicht mehr so sinnvoll wie damals. Entwicklungsumgebungen haben Syntaxhervorhebung und erzählen zu den einzelnen Dingen des Codes deren Kontext und Metadaten mit einfachem Mausdraufhalten.

Wichtiger ist aber im Zusammenhang mit Javascript, dass mit const deklarierte Variablen keine Konstanten im herkömmlichen Sinne sind. Es sind lediglich Variablen, deren Wert sich nach der Zuweisung nicht mehr ändert. Ansonsten haben sie keine Extrastellung und müssen auch nicht anders behandelt werden als andere Variablen.

Ich würde solche Variablen auch nicht als Konstante bezeichnen, sondern als unveränderliche Variablen. Der Unterschied zu herkömmlichen Konstanten ist auch, dass für letztere die Werte üblicherweise zur Compilezeit feststanden und direkt als fester Wert im Compilat abgelegt wurden. const-Variablen in Javascript werden aber im Gegensatz dazu sehr oft auch als Ablagen für Zwischenergebnisse verwendet.

dedlfix.

[dedlfix]

Tach!

P.S.: Code ist keine Sammlung von tabellarischen Daten. Ich halte es deshalb nicht für sinnvoll, ihn wie eine (unsichtbare) Tabelle zu formatieren.

const jahr     = 2020;
let   jahrtext = "Wir schreiben das Jahr ";
let   ausgabe  = jahrtext + jahr;

Man könnte zwar kategorisieren, in der linken Spalte sind Schlüsselwörter, in der mittleren Variablennamen und in der rechten Ausdrücke, doch solche Zusammenhänge sind eher philosophischer Natur und nicht praxisrelevant. Die Zusammenhänge sind vielmehr zeilenweise, so dass die Zeilen in sich einen optischen Zusammenhang bilden müssen und nicht die für das Verständnis der jeweiligen Zeile oftmals nicht weiter relevanten Vorgänger- und Nachfolgerzeilen.

Besonders wenn einzelne "Spalten" durch Ausreißer (wie langer Variablenname) soweit ausgedehnt werden, dass es schwerer wird zu erkennen, welcher Ausdruck nun zu welchem Variablennamen und welchem Schlüsselwort gehört, überwiegen die Nachteile in der Lesbarkeit der vermeintlich besseren Ästhetik.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

const jahr     = 2020;
let   jahrtext = "Wir schreiben das Jahr ";
let   ausgabe  = jahrtext + jahr;

Eine gewisse Strukturierung finde ich aber nicht verkehrt.

const jahr = 2021;

let jahrtext = "Wir schreiben das Jahr ",
    ausgabe = jahrtext + jahr;

Bis demnächst
Matthias

[dedlfix]

Tach!

Eine gewisse Strukturierung finde ich aber nicht verkehrt.

Generell ja, aber dann so, dass Sinneinheiten leichter erkennbar sind. Sprich, wenn mehrere Zeilen zusammengehören, dann sollte man sie mit Leerzeilen davor und danach trennen, solange es nicht noch bessere Strukturierungsmöglichkeiten gibt, wie Auslagerung in eine Funktion/Methode. Zeilen bilden Sinnzusammenhänge, Spalten jedoch nicht.

const jahr = 2021;

let jahrtext = "Wir schreiben das Jahr ",
    ausgabe = jahrtext + jahr;

Einrückungen, um Blöcke und den Umbruch langer Zeilen kenntlich zu machen, sind nicht Gegenstand meiner Kritik.

Unabhängig davon kann man darüber streiten, ob man mehrere Variablendefinitionen in einer einzelnen Anweisung kommasepariert notiert oder doch lieber jede Variable einzeln. Ich bevorzuge letzteres, weil damit das Refakturieren einfacher geht. Ich kann dann die Anweisungen zeilenweise behandeln und muss nicht darauf achten, dass der ganze Block intakt bleibt.

dedlfix.

[Matthias Scharwies]

Servus!

Unabhängig davon kann man darüber streiten, ob man mehrere Variablendefinitionen in einer einzelnen Anweisung kommasepariert notiert oder doch lieber jede Variable einzeln. Ich bevorzuge letzteres, weil damit das Refakturieren einfacher geht. Ich kann dann die Anweisungen zeilenweise behandeln und muss nicht darauf achten, dass der ganze Block intakt bleibt.

Ab wann würdest du mehrere zusammengehörende Variablen in einem Objekt / einer class zusammenfassen?

Möglichst oft? Nur, wenn es wirklich passt?

Herzliche Grüße

Matthias Scharwies

[Der Martin]

Moin,

Unabhängig davon kann man darüber streiten, ob man mehrere Variablendefinitionen in einer einzelnen Anweisung kommasepariert notiert oder doch lieber jede Variable einzeln. Ich bevorzuge letzteres, weil damit das Refakturieren einfacher geht. Ich kann dann die Anweisungen zeilenweise behandeln und muss nicht darauf achten, dass der ganze Block intakt bleibt.

Ab wann würdest du mehrere zusammengehörende Variablen in einem Objekt / einer class zusammenfassen?

wenn sie durch das Zusammenfassen zu einem Objekt eine in sich abgeschlossene Sinneinheit bilden. Also nicht zusammenfassen um jeden Preis, wenn dabei ein Konstrukt herauskäme, das Schrauben und Knödel vermischt.

Und wenn es ein Objekt Schraube ergeben soll, dann wiederum komplett mit allen relevanten Eigenschaften, also Länge, Durchmesser, Schraubenkkopf-Ausführung, Gewindetyp, Material.

Möglichst oft? Nur, wenn es wirklich passt?

Letzteres.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

Ab wann würdest du mehrere zusammengehörende Variablen in einem Objekt / einer class zusammenfassen?

Möglichst oft? Nur, wenn es wirklich passt?

Strongly depends. Ich entscheide das nach Sinnhaftigkeit, nicht nach Prinzipien. Ein Objekt zu bilden muss auch fachlich gerechtfertigt sein. Als Faustregel könnte man anführen, das ein Objekt/Klasse sinnvoll ist, wenn man ihm/ihr einen beschreibenden Namen geben kann, aber nicht solche Meta-Namen wie "data" oder "record". So ein Name hilft auch dem Leser (inklusive Zukunfts-Ich), den Sinn besser zu erfassen.

dedlfix.

[Matthias Scharwies]

Servus!

Tach!

P.S.: Code ist keine Sammlung von tabellarischen Daten. Ich halte es deshalb nicht für sinnvoll, ihn wie eine (unsichtbare) Tabelle zu formatieren.

const jahr     = 2020;
let   jahrtext = "Wir schreiben das Jahr ";
let   ausgabe  = jahrtext + jahr;

Man könnte zwar kategorisieren, in der linken Spalte sind Schlüsselwörter, in der mittleren Variablennamen und in der rechten Ausdrücke, doch solche Zusammenhänge sind eher philosophischer Natur und nicht praxisrelevant. Die Zusammenhänge sind vielmehr zeilenweise, so dass die Zeilen in sich einen optischen Zusammenhang bilden müssen und nicht die für das Verständnis der jeweiligen Zeile oftmals nicht weiter relevanten Vorgänger- und Nachfolgerzeilen.

Besonders wenn einzelne "Spalten" durch Ausreißer (wie langer Variablenname) soweit ausgedehnt werden, dass es schwerer wird zu erkennen, welcher Ausdruck nun zu welchem Variablennamen und welchem Schlüsselwort gehört, überwiegen die Nachteile in der Lesbarkeit der vermeintlich besseren Ästhetik.

dedlfix.

Hallo dedlfix,

vielen Dank für solch Grundsätzlichen Hinweise, Betrachtungen und Erklärungen. Ich werde das Bsp. korrigieren und versuche das irgendwo einzubauen

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo dedlfix,

ist das eine Norm, oder dein persönlicher Codestyle?

Ich bin nämlich ebenfalls ein Fan von solchen tabellarischen Formatierungen, wobei mir bewusst ist, dass Längenausreißer kontraproduktiv sind. Eine Gliederung mit Leerzeilen ist ebenfalls nötig.

Eine Sortierung nach const und let hilft zumeist auch, wobei noch der Aspekt hinzukommt, dass man thematisch zusammenhängende Variablen auch nahe beieinander deklarieren sollte.

Wobei die Alarmglocke gleich nebenan zu stehen hat. Wenn ich anfange, mir Gedanken über die Gliederung einer längeren Deklarationsliste zu machen, sollte ich damit aufhören, die Axt in die Hand nehmen und nach den Stellen suchen, an denen ich die Klasse bzw. Methode zerbröseln kann.

Rolf

[dedlfix]

Tach!

ist das eine Norm, oder dein persönlicher Codestyle?

Vielleicht ersteres, aber vor allem letzteres.

Ich bin nämlich ebenfalls ein Fan von solchen tabellarischen Formatierungen, wobei mir bewusst ist, dass Längenausreißer kontraproduktiv sind.

Es sieht vielleicht auf den ersten Blick schön aus, aber der Aufwand, das schön zu halten, erhöht sich mit jeder Zeile, die hinzukommt oder wegfällt. (Ja, es gibt Formatierungshilfen dafür in den IDEs.)

Eine Gliederung mit Leerzeilen ist ebenfalls nötig.

Unbestritten.

Eine Sortierung nach const und let hilft zumeist auch, wobei noch der Aspekt hinzukommt, dass man thematisch zusammenhängende Variablen auch nahe beieinander deklarieren sollte.

Mir nicht. Bei mir ist es so, dass die meisten Variablen sowieso const sind und let die Ausnahme bildet. Zudem sortiere ich nicht die Deklarationen an den Anfang von Blöcken, sondern habe sie da, wo die Variable gebraucht wird. Es ist auch fachlich notwendig, sie dort zu haben, wo ihr Ausdruck berechnet werden kann, sonst müsste man let-Variablen verwenden

something;
const foo = kann_erst_hier_berechnet_werden;
something;

vs.

let foo;

something;
foo = kann_erst_hier_berechnet_werden;
something;

Insofern habe ich selten das Bedürfnis, solche Variablen zu sortieren.

Bei Propertys in Klassen ist das anders, die sind per se außerhalb aller Blöcke (Methoden) und tummeln sich deshalb am Anfang der Klasse. Aber auch da sortiere ich nicht nach readonly oder nicht, oder public/private, sondern nach Sinnzusammenhang.

dedlfix.

[Rolf B]

Hallo Matthias,

Ja, ich mach mich grad drüber.

Oha - ich habe gestern ein paar Stunden dran gearbeitet, war aber nicht fertig und habe die Änderung erstmal lokal auf Halde gelegt. Bzw. ich stelle sie dann mal in meinen Userspace.

Rolf