Syntax, Variablen und primitive Datentypen

JavaScript — Syntax und Datentypen

0:00 Im letzten Modul lief der erste Code. Jetzt geht es um das Material, aus dem dieser Code besteht. Das klingt nach Grundlagenarbeit — und genau das ist es auch. Aber es ist die Art Grundlagenarbeit, die sich über Jahre auszahlt: Wer weiß, was ein Ausdruck ist, warum es drei Schlüsselwörter für Variablen gibt und weshalb null und undefined nicht dasselbe sind, liest fremden Code später mit einer Selbstverständlichkeit, die von außen wie Talent aussieht.

0:26 Nehmen Sie sich für dieses Modul Zeit. Alles, was ab Modul drei kommt, steht auf diesen Bausteinen.

Das Fundament der Sprache

0:32 Sieben Kapitel, und sie bauen streng aufeinander auf. Wir beginnen mit den Regeln, nach denen die Engine überhaupt liest — Syntax also. Dann Kommentare, die zwar niemand ausführt, die aber über die Lebensdauer eines Projekts mitentscheiden. Danach Variablen und die Frage, welches Schlüsselwort wann richtig ist. Der Mittelteil bringt die Datentypen im Überblick, bevor wir uns drei davon genauer ansehen: Wahrheitswerte, Zeichenketten und Zahlen.

0:58 Hier lohnt Gründlichkeit mehr als Tempo — diese Bausteine begleiten Sie durch das gesamte Seminar.

Syntax

1:05 Fangen wir mit den Spielregeln an. Syntax entscheidet zunächst nur darüber, ob die Engine Ihren Code überhaupt annimmt. Aber sie ist nur die halbe Miete — der interessantere Teil kommt am Ende dieses Kapitels. Syntax ist das Regelwerk für die Anordnung von Zeichen — vergleichbar mit der Grammatik einer natürlichen Sprache. Halten Sie die Regeln ein, entsteht gültiges JavaScript.

1:28 Verletzen Sie sie, weigert sich die Engine, den Code auszuführen, und meldet einen Syntaxfehler. Das klingt streng, ist aber die freundlichste Art von Fehler, die es gibt: Sie merken es sofort, nicht erst beim Kunden. Wichtig ist die Grenze dieser Definition. Syntax sagt Ihnen, ob ein Satz grammatikalisch korrekt ist — nicht, ob er verständlich ist. Grammatikalisch korrekten Unsinn kann man in jeder Sprache schreiben.

1:54 Hinter diesen vier Begriffen steckt eine Unterscheidung, die sich durch die ganze Sprache zieht: Manches tut etwas, manches ergibt etwas. Eine Anweisung ist eine Handlung — mach das. Ein Ausdruck ist eine Rechnung, an deren Ende ein Wert steht. Zwei plus drei ist ein Ausdruck; er ergibt fünf, er tut nichts. Schlüsselwörter sind die Wörter, die sich die Sprache selbst reserviert hat, Bezeichner die Namen, die Sie vergeben. Diese Liste müssen Sie nicht auswendig lernen.

2:22 Schlüsselwörter merkt man sich beim Benutzen, und der Editor macht sie ohnehin sofort farbig sichtbar. Schauen Sie auf die mittlere Zeile: Dort steckt alles auf einmal. Das Schlüsselwort kündigt an, dass eine Variable entsteht. Der Bezeichner ist der Name, den Sie frei wählen. Rechts vom Gleichheitszeichen steht der Ausdruck, der ausgewertet wird — und sein Ergebnis landet im Namen. Die letzte Zeile ist die eigentliche Pointe.

2:48 Zwei Anweisungen in einer Zeile sind vollkommen gültig; die Engine hat damit kein Problem. Ihre Kollegin beim Durchsehen aber schon. Genau hier trennt sich, was erlaubt ist, von dem, was sinnvoll ist — und wir schreiben Code für Menschen. Das Semikolon ist eine der beliebtesten Streitfragen der JavaScript-Welt, und die Sache ist erklärungsbedürftig.

3:10 Die Sprache ergänzt fehlende Semikolons automatisch — ein Mechanismus mit dem Kürzel ASI. Meistens rät sie richtig. In wenigen, aber bösartigen Fällen setzt sie das Semikolon anders, als Sie es gemeint hatten, und dann suchen Sie einen Fehler, den Sie gar nicht geschrieben haben. Solange Sie lernen, empfehle ich deshalb klar: Setzen Sie es. Es macht das Ende einer Anweisung eindeutig, für die Engine und für Sie.

3:35 Ein Team kann sich später bewusst anders entscheiden — bewusst ist das Stichwort. Diese Aufgabe hat einen Ehrgeiz, der über Formatierung hinausgeht. Sie nehmen eine gedrängte, aber vollkommen gültige Zeile und lösen sie so auf, dass jede Anweisung ihre eigene Zeile bekommt. Danach prüfen Sie mit Node, dass die Ausgabe unverändert ist.

3:55 Der Nachweis ist wichtig, denn er zeigt Ihnen schwarz auf weiß: Die Engine ist völlig gleichgültig, wie Sie das schreiben. Der Unterschied entsteht ausschließlich für den Menschen, der das später liest. Und dieser Mensch sind in den meisten Fällen Sie selbst, ein halbes Jahr später. Der teuerste Irrtum in diesem Kapitel ist, Formatierung für Kosmetik zu halten.

4:16 Sie entscheidet darüber, ob ein Projekt in zwei Jahren noch wartbar ist — das ist kein ästhetisches, sondern ein wirtschaftliches Thema. Der zweite Punkt schließt an die Semikolon-Frage an: Sich auf die automatische Ergänzung zu verlassen, ohne ihre Ausnahmen zu kennen, ist ein Spiel mit unnötigem Risiko. Und die Bezeichner: Wenn der Zweck eines Namens sich erst aus der Umgebung erschließt, ist der Name zu schwach.

4:40 Dass mehrere Anweisungen pro Zeile erlaubt sind, ist übrigens kein Argument dafür, es zu tun.

Kommentare und Hashbang

4:46 Jetzt zu einem Teil des Codes, den die Engine komplett ignoriert — und der trotzdem großen Einfluss hat. Kommentare richten sich an Menschen und an Werkzeuge. Beides ist interessanter, als es zunächst klingt. Ein Kommentar ist Text im Quelltext, den die Engine überliest, als stünde er nicht da. Sie können ihn ändern, kürzen, ganz entfernen — am Verhalten des Programms ändert sich nichts.

5:10 Genau daraus folgt aber das eigentliche Risiko: Weil nichts kaputtgeht, wenn ein Kommentar nicht mehr stimmt, merkt es auch niemand. Ein veralteter Kommentar ist deshalb schlimmer als gar keiner. Er behauptet etwas mit der Autorität des Quelltexts und führt in die Irre. Was Menschen und Werkzeuge daraus lesen, verändert Kommentare durchaus — nur eben nicht die Ausführung.

5:32 Drei Formen mit unterschiedlichen Aufgaben. Der einzeilige Kommentar ist der Alltagsfall — eine kurze Bemerkung am Rand. Der mehrzeilige nimmt längere Erklärungen auf. Der dritte mit dem doppelten Stern ist der interessanteste: Er ist ein Dokumentationskommentar, den Werkzeuge auslesen können, sodass Ihr Editor später beim Aufruf einer Funktion Hinweise einblendet.

5:54 Die vorletzte Zeile zeigt noch eine ganz andere Sorte: Sie ist eine Anweisung an ein Prüfwerkzeug, verpackt als Kommentar. Und ganz oben der Hashbang — er sagt dem Betriebssystem, womit die Datei auszuführen ist. Der muss zwingend in Zeile eins stehen. Die brauchbarste Regel lautet: Ein Kommentar erklärt das Warum, nicht das Was. Was passiert, steht bereits im Code, und zwar zuverlässiger als in jedem Kommentar.

6:19 Warum es passiert — welche fachliche Regel dahintersteckt, welcher Sonderfall abgefangen wird, warum die naheliegende Lösung hier nicht funktioniert — das steht nirgends sonst. Dazu kommt die Werkzeugebene: Prüfwerkzeuge wie ESLint lesen bestimmte Kommentare als Anweisung an sich selbst. Und die Gegenprobe ist genauso wichtig: Ist der Code bereits eindeutig, braucht er keinen Kommentar. Weniger und dafür gehaltvoller ist hier die bessere Richtung.

6:46 Nehmen Sie einen Kommentar, der die Zeile nur nacherzählt — davon gibt es in fast jedem Projekt reichlich — und ersetzen Sie ihn durch einen, der den Grund erklärt. Die Probe dafür ist erfreulich einfach: Verrät der Kommentar etwas, das der Code nicht schon sagt? Wenn nein, weg damit. Wenn ja, behalten. Diese kleine Frage werden Sie in Code-Reviews noch oft stellen, in eigenen wie in fremden.

7:10 Sie ist einer der wenigen Qualitätstests, die ohne Werkzeug funktionieren und trotzdem verlässlich sind. Der gefährlichste Kommentar ist der, der beim Ändern des Codes stehen geblieben ist. Er wird zur Falschaussage und kostet den nächsten Leser echte Zeit. Das Gegenstück ist der Kommentar-Overkill: Wer jede Zeile beschriftet, verstellt den Blick auf die Stellen, an denen eine Erklärung wirklich nötig wäre.

7:34 Beim Hashbang gilt schlicht die Positionsregel — nicht in Zeile eins, keine Wirkung, und die Fehlersuche ist entsprechend ratlos. Und auskommentierter Code, der monatelang liegen bleibt: Dafür gibt es die Versionsverwaltung. Sie vergisst nichts, im Gegensatz zu dem Kollegen, der den Block einmal stehen ließ.

Variablen

7:52 Jetzt kommt eines der Kapitel, deren Faustregel Sie täglich anwenden werden. Es geht um drei Schlüsselwörter, von denen Sie zwei benutzen und eines nur erkennen müssen. Klingt einfach — und ist es auch, sobald man den Grund dahinter kennt. Eine Variable ist ein benannter Platz für einen Wert. Das Bild vom Schubfach passt ganz gut: Sie beschriften ein Fach und legen etwas hinein.

8:15 Drei Zutaten braucht es dafür — ein Schlüsselwort, das die Variable erzeugt, einen Namen und eine Zuweisung. Der entscheidende Punkt steckt im Schlüsselwort: Es legt fest, ob Sie den Inhalt des Fachs später gegen einen anderen austauschen dürfen. Diese eine Entscheidung treffen Sie in Zukunft bei jeder einzelnen Variablen, und sie sagt jedem Leser sofort etwas darüber, wie sich Ihr Code verhalten wird.

8:38 Die Logik dahinter lässt sich auf einen Satz eindampfen: const zuerst, let bei Bedarf, var gar nicht. Warum diese Reihenfolge? Weil const nicht nur eine technische Sperre ist, sondern eine Aussage. Es signalisiert dem Leser: Dieser Wert bleibt, du musst ihn im weiteren Verlauf nicht im Auge behalten. Das reduziert die Menge an Dingen, die man beim Lesen gleichzeitig im Kopf haben muss — und genau das ist der Engpass beim Verstehen von Code.

9:05 Das ursprüngliche var hat Eigenheiten, die regelmäßig überraschen. Sie werden ihm in älterem Code begegnen; erkennen genügt, schreiben nicht. Zwei Themen in einem Beispiel. Oben die Entscheidung zwischen fest und veränderlich: Der Beetname bleibt, die Zahl der Gießungen darf sich ändern. Der auskommentierte Versuch zeigt, was passiert, wenn man gegen const anschreibt — es gibt einen Fehler, und zwar sofort.

9:29 Unten geht es um Namen, und der Unterschied ist eklatant: Ein einzelner Buchstabe ist gültig und völlig nichtssagend, der ausgeschriebene Name erklärt sich selbst. Erlaubt sind Buchstaben, Ziffern, Dollarzeichen und Unterstrich — nur nicht eine Ziffer als erstes Zeichen. Und die übliche Schreibweise ist camelCase, also Binnengroßschreibung ohne Trennzeichen.

9:50 Hier zahlt sich aus, was wir im ersten Modul geklärt haben. Der Typ hängt am Wert, nicht an der Variablen — Sie kündigen also nirgends an, was in ein Fach kommt. Eine mit let angelegte Variable darf sogar später einen Wert ganz anderen Typs aufnehmen. Das ist bequem und spart Schreibarbeit. Es ist aber auch eine der häufigsten Fehlerquellen der Sprache, weil niemand Sie warnt, wenn aus einer Zahl unversehens ein Text wird.

10:14 Erfreulich ist der letzte Punkt: Um das Aufräumen des Speichers kümmert sich die Laufzeitumgebung selbst. Freigeben müssen Sie nichts. Beschreiben Sie zwei Beete des Kiezgartens mit je drei Werten — und treffen Sie dabei jede Entscheidung zwischen const und let bewusst. Der Nachweis ist streng formuliert: Überall dort, wo Sie nie einen zweiten Wert zuweisen, steht const. Und jedes let ist durch eine tatsächliche Neuzuweisung im Code belegt.

10:39 Diese Übung wirkt kleinlich, sie ist aber der schnellste Weg zu einer Gewohnheit, die Sie danach nicht mehr ablegen. Nach ein paar Tagen greifen Sie automatisch zu const und merken es selbst kaum noch. JavaScript unterscheidet Groß- und Kleinschreibung, und das führt zu einem besonders zähen Fehler: zwei Variablen, die sich nur darin unterscheiden.

11:00 Der Code läuft, tut aber etwas anderes als gedacht. Der zweite Punkt ist Gewohnheit — wer aus anderen Sprachen kommt, tippt let, ohne nachzudenken. Heikler ist der dritte: einer Variablen später einen Wert ganz anderer Bedeutung geben. Technisch erlaubt, für den Leser eine Falle, weil der Name dann etwas anderes verspricht, als drinsteckt.

11:21 Und var übernehmen, nur weil es in einem alten Beispiel stand — das passiert häufiger, als man denkt.

Datentypen

11:28 Jetzt der Überblick über die Werte selbst. Eine einzige Unterscheidung ist dabei so wichtig, dass sie uns bis in die Module über Arrays und Objekte begleiten wird — und viele spätere Überraschungen im Voraus erklärt. Die große Zweiteilung lautet: primitive Werte auf der einen Seite, Objekte auf der anderen. Primitive Werte sind die einfachsten Bausteine — eine Zahl, ein Text, ein Ja oder Nein.

11:51 Objekte sind zusammengesetzt. Der entscheidende Unterschied ist aber nicht die Größe, sondern die Veränderlichkeit: Primitive Werte sind unveränderlich. Man kann eine Drei nicht in eine Vier verwandeln, man kann nur eine Vier an ihre Stelle setzen. Objekte dagegen lassen sich nachträglich umbauen, ohne dass ein neues entsteht.

12:11 Merken Sie sich diesen Satz. Er erklärt später eine ganze Reihe von Effekten, die sonst wie Zauberei wirken. Sieben primitive Typen — und was diese Liste eigentlich zeigt, ist ihre Knappheit. Alles andere, was Ihnen in JavaScript begegnet, ist ein Objekt: Arrays, Datumswerte, sogar Funktionen. Zwei Zeilen verdienen besondere Aufmerksamkeit, weil sie sich ähnlich anfühlen und Verschiedenes bedeuten.

12:36 Undefined heißt: Hier wurde nie ein Wert zugewiesen — das Fach ist leer, weil niemand etwas hineingelegt hat. Null heißt: Hier wurde bewusst Leere gesetzt — jemand hat entschieden, dass hier nichts ist. Der Unterschied klingt spitzfindig, ist in der Praxis aber genau der Unterschied zwischen einem Versehen und einer Absicht.

12:56 Dieses Beispiel führt den Unterschied aus der Definition direkt vor. Oben wird eine Zeichenkette in Großbuchstaben ausgegeben — und danach steht in der Variablen unverändert der alte Wert. Die Methode hat nichts geändert, sie hat eine neue Zeichenkette zurückgegeben. Wer das nicht weiß, sucht den Fehler an der falschen Stelle.

13:15 Unten dagegen wird ein Objekt tatsächlich verändert, und zwar obwohl es mit const angelegt ist. Auch das ist konsequent: const schützt die Bindung — welches Objekt im Fach liegt —, nicht den Inhalt des Objekts. Und typeof gibt Ihnen jederzeit Auskunft über die Art des Werts. Weisen Sie beides praktisch nach: eine Zeichenkette, die nach einem Methodenaufruf unverändert dasteht, und ein Objekt, dessen Eigenschaft sich geändert hat.

13:40 Es geht nicht darum, etwas Neues zu bauen — es geht darum, den Unterschied einmal selbst gesehen zu haben, statt ihn zu glauben. Zum Prüfen hilft typeof. Halten Sie dabei die Augen offen: Bei null liefert typeof ein historisch gewachsenes Kuriosum, das seit Jahrzehnten aus Kompatibilitätsgründen erhalten bleibt. Was dort steht, verrate ich nicht — schauen Sie selbst nach, der Aha-Effekt lohnt sich.

14:04 Die Erwartung, dass eine String-Methode das Original verändert, ist der Klassiker dieses Kapitels — sie tut es nie, sie liefert Neues zurück. Fast ebenso häufig: die Annahme, const mache ein Objekt unveränderlich. Es schützt nur, welches Objekt in der Variablen liegt; alles darin bleibt offen. Dritter Punkt: typeof ist praktisch, aber keine vollständige Typprüfung — bei null führt es nachweislich in die Irre.

14:29 Und der grundsätzlichste Irrtum zum Schluss: Dynamische Typisierung macht Typkenntnis nicht überflüssig, sondern wichtiger. Die Sprache nimmt Ihnen die Deklaration ab, nicht das Nachdenken.

Wahrheitswerte einsetzen

14:41 Ein kurzes Kapitel, aber eines mit großer Reichweite. Alles, was später entschieden, verzweigt und geschleift wird, läuft am Ende auf zwei Werte hinaus: wahr oder falsch. Umso wichtiger, dass sie sauber modelliert sind. Zwei Ausprägungen, mehr gibt es nicht: true und false. Beide werden kleingeschrieben, und beide stehen ohne Anführungszeichen.

15:03 Dieser zweite Hinweis klingt banal, ist aber der häufigste Fehler des ganzen Kapitels. Setzen Sie Anführungszeichen darum, haben Sie keinen Wahrheitswert mehr, sondern einen Text, der zufällig wie einer aussieht. Und Texte verhalten sich beim Entscheiden anders — der Text mit dem Wort „false" darin gilt nämlich als wahr. In der Konsole sehen beide fast gleich aus.

15:26 Genau deshalb ist dieser Fehler so zäh in der Fehlersuche. Zwei Dinge zeigt dieses Beispiel. Erstens das Ausrufezeichen, das als „nicht" gelesen wird: Es dreht einen Wahrheitswert um. Praktisch gedacht — statt zu fragen, ob etwas gegossen ist, fragen Sie, ob es nicht gegossen ist. Zweitens die Gegenüberstellung ganz unten, und die ist der eigentliche Lernpunkt.

15:48 Zwei Variablen, die auf dem Bildschirm nahezu identisch aussehen, und typeof entlarvt sie als völlig verschieden. Der eine Wert ist ein boolean, der andere ein string. Machen Sie sich zur Gewohnheit, bei unerklärlichen Entscheidungen genau diese Prüfung durchzuführen. Diese Namenskonvention wirkt wie eine Stilfrage, ist aber Kommunikation. Ein Präfix wie is oder has kündigt an: Von dieser Variablen sind nur zwei Werte zu erwarten.

16:15 Der Leser muss nicht suchen, was drinstehen könnte. Dazu kommt ein Effekt, den man erst beim Vorlesen bemerkt: Der Code liest sich wie eine Frage — ist gegossen, hat Ertrag, kann geerntet werden. Und die Negation bleibt verständlich, weil das Ausrufezeichen davor sprachlich funktioniert. Die Faustregel dahinter ist einfach: Alles, was sich als Ja-Nein-Frage formulieren lässt, gehört in eine solche Variable.

16:40 Nehmen Sie drei Zustände eines Beetes und legen Sie sie als echte Wahrheitswerte ab — nicht als Text. Der Nachweis ist dreiteilig: typeof bestätigt den Typ, die Negation liefert das erwartete Gegenteil, und keiner der Werte steht in Anführungszeichen. Achten Sie besonders auf den letzten Punkt, denn er ist der, an dem es in der Praxis schiefgeht — vor allem, wenn Werte aus Konfigurationsdateien oder aus Formularen kommen.

17:05 Dort ist alles zunächst Text, und die Umwandlung müssen Sie bewusst vornehmen. Der Text statt des Wahrheitswerts ist hier der Dauerbrenner, und er wird Ihnen im Berufsalltag wiederbegegnen — spätestens dort, wo Werte aus Umgebungsvariablen kommen, die immer Text sind. Der zweite Punkt ist ein Import aus anderen Sprachen: Python schreibt True groß, JavaScript kennt nur die Kleinschreibung und meldet den großgeschriebenen Namen als unbekannt.

17:30 Wahrheitswerte in Variablen ohne sprechendes Präfix zu verstecken, kostet den Leser jedes Mal einen Umweg. Und die doppelte Verneinung: Technisch harmlos, für das Verständnis ein Bremsklotz. Zwei Ausrufezeichen hintereinander sind fast immer ein Hinweis auf eine bessere Formulierung.

Zeichenketten erstellen und nutzen

17:47 Jetzt zum Typ, mit dem Sie vermutlich am meisten arbeiten werden. Text steckt in Ausgaben, in Namen, in Dateipfaden, in allem, was ein Mensch am Ende liest. Ein modernes Sprachmittel wird uns dabei den ganzen Kurs begleiten. Drei Möglichkeiten, Text zu notieren: einfache Anführungszeichen, doppelte Anführungszeichen und Backticks.

18:08 Die ersten beiden sind gleichwertig — reine Geschmackssache, solange man innerhalb eines Projekts konsistent bleibt. Die Backticks sind die interessante Neuerung. Sie erlauben zweierlei: eingebettete Ausdrücke mitten im Text und echte Zeilenumbrüche, ohne Sonderzeichen. Das klingt nach einer Kleinigkeit, verändert aber spürbar, wie lesbar Textzusammenbau aussieht.

18:29 Wir werden diese Form ab hier konsequent verwenden, und Sie werden sie in jedem modernen Projekt wiederfinden. Die beiden Zeilen in der Mitte sagen dasselbe — und sie sagen es sehr unterschiedlich gut. Die erste setzt Text mit Plus-Operatoren zusammen; man muss beim Lesen mitzählen, wo Leerzeichen stehen und wo nicht. Die zweite schreibt einfach hin, wie das Ergebnis aussehen soll, mit Platzhaltern an den passenden Stellen.

18:55 Wichtig ist der Blick darunter: In so einem Platzhalter darf ein ganzer Ausdruck stehen, nicht nur ein Name — hier wird sogar gerechnet. Und der letzte Block zeigt die zweite Fähigkeit: Der Zeilenumbruch steht einfach im Text und landet genau so in der Ausgabe. Diese Sammlung hat ein gemeinsames Prinzip, und das ist wichtiger als jeder einzelne Eintrag: Keine dieser Methoden verändert das Original.

19:18 Alle liefern ein neues Ergebnis zurück — die Unveränderlichkeit aus Kapitel vier in der Praxis. Zwei Details lohnen den Blick. Die Länge ist eine Eigenschaft, keine Methode, steht also ohne Klammern. Und die Zugriffsmethode erlaubt negative Positionen, sodass man mit minus eins bequem das letzte Zeichen bekommt, ohne vorher zu rechnen.

19:38 Sonst gilt: Suchmethoden melden entweder eine Position oder einen Wahrheitswert — je nachdem, was Sie eigentlich wissen wollen. Bauen Sie aus drei Variablen eine mehrzeilige Beschriftung zusammen — und zwar ohne einen einzigen Plus-Operator. Diese Einschränkung ist der eigentliche Zweck der Übung: Sie zwingt zum Template-Literal und macht den Unterschied körperlich spürbar.

20:00 Geben Sie am Ende noch die Länge des Ergebnisses aus. Zwei Hinweise für den Zugriff auf einzelne Zeichen: Der Index beginnt bei null, nicht bei eins. Und wenn Sie von hinten zugreifen wollen, ist die Methode mit dem negativen Index deutlich angenehmer als jede Rechnung mit der Länge. Der Index ab null ist der Fehler, den jeder einmal macht — und in fast jeder Programmiersprache erneut.

20:23 Die Länge mit Klammern aufzurufen, ist ebenfalls ein Klassiker; das Ergebnis ist keine hilfreiche Fehlermeldung, sondern ein rätselhafter Zustand. Besonders tückisch ist der dritte Punkt: Die einfache Ersetzungsmethode ersetzt nur den ersten Treffer, nicht alle. Wer das nicht weiß, wundert sich über halb bereinigte Texte.

20:42 Und das Escapen: Ein Anführungszeichen im Text, das nicht markiert ist, beendet die Zeichenkette an Ort und Stelle — mit einer Fehlermeldung, die auf die Folgezeile zeigt.

Zahlenwerte speichern

20:52 Zum Abschluss die Zahlen. Und gleich vorweg: Hier wartet die vielleicht bekannteste Überraschung der Sprache — eine, die nichts mit JavaScript zu tun hat, sondern mit der Art, wie Computer Kommazahlen speichern. JavaScript macht es sich an einer Stelle bemerkenswert einfach: Es gibt keinen Unterschied zwischen Ganzzahlen und Kommazahlen. Ein einziger Typ deckt beides ab.

21:14 Das erspart Ihnen die Entscheidung, die in anderen Sprachen ständig ansteht, hat aber einen Preis, den wir gleich sehen. Für sehr große Ganzzahlen gibt es einen zweiten Typ, BigInt, der außerhalb des sicher darstellbaren Bereichs zuverlässig weiterrechnet. Erzeugt wird er durch ein angehängtes kleines n — eine unscheinbare Markierung mit großer Wirkung, denn sie wechselt den Typ.

21:36 Die erste Zeile ist die berühmteste, und Sie sollten sie einmal selbst laufen lassen. Null Komma eins plus null Komma zwei ergibt eben nicht glatt null Komma drei, sondern eine Zahl mit einem winzigen Rest hinten dran. Das ist kein Fehler von JavaScript, sondern die Folge davon, dass Kommazahlen binär gespeichert werden — manche Werte lassen sich dort nicht exakt abbilden, so wie ein Drittel im Dezimalsystem.

21:59 Darunter zwei reine Lesehilfen: Unterstriche in großen Zahlen werden ignoriert, die Exponentialschreibweise kürzt viele Nullen ab. Und unten der große Bereich, in dem nur BigInt noch exakt bleibt. Die Antwort ist erfreulich pragmatisch: fast nie. Der normale Zahlentyp deckt praktisch jeden Alltagsfall ab, und wer vorsorglich überall BigInt einsetzt, handelt sich Einschränkungen ein, ohne einen Nutzen zu haben.

22:24 Interessant wird es bei sehr großen Ganzzahlen, die typischerweise von außen kommen — lange Identifikationsnummern aus Fremdsystemen etwa. Ob ein Wert noch exakt ist, müssen Sie dabei nicht schätzen: Es gibt eine Prüffunktion, die genau diese Frage beantwortet. Und ein technischer Punkt mit praktischen Folgen: Die beiden Zahlentypen lassen sich nicht miteinander verrechnen. Man muss sich für einen entscheiden.

22:48 Zeigen Sie eine Ganzzahl, für die die Prüffunktion meldet, dass sie nicht mehr sicher darstellbar ist — die Obergrenze liefert Ihnen eine eingebaute Konstante. Und dann rechnen Sie denselben Wert korrekt als BigInt. Der Kontrast ist der Lerneffekt: Dieselbe Zahl, einmal ungenau und einmal exakt. Wer das einmal gesehen hat, stellt bei Identifikationsnummern aus fremden Systemen künftig die richtige Frage — nämlich, ob der Wert unterwegs noch heil ist.

23:15 Das ist ein Fehler, der in echten Projekten leise passiert und teuer wird. Geldbeträge in Kommazahlen sind der teuerste Punkt dieser Liste, und zwar wörtlich. Die kleinen Ungenauigkeiten summieren sich, und am Ende stimmt eine Abrechnung um Cent-Beträge nicht — mit erheblichem Aufwand bei der Klärung. Dafür gibt es eigene Strategien, etwa in ganzen Cent zu rechnen.

23:37 Beim BigInt sind es zwei mechanische Fallen: die Vermischung mit gewöhnlichen Zahlen, die einen Fehler auslöst, und das vergessene n am Ende, das still einen anderen Typ erzeugt. Und der letzte Punkt gilt allgemein: Vorsorge, die niemand braucht, ist keine Vorsorge, sondern zusätzliche Komplexität.

Die Bausteine stehen

23:55 Halten wir die vier Sätze fest, die dieses Modul trägt. Syntax macht Code gültig, Formatierung macht ihn lesbar — beides ist nötig, und nur eines davon prüft die Engine. Bei Variablen gilt: const zuerst, let bei echter Neuzuweisung, var nur beim Lesen fremden Codes erkennen. Und die Unterscheidung, die uns am längsten begleiten wird: Primitive Werte sind unveränderlich, Objekte nicht. Damit steht das Material.

24:20 Im nächsten Modul setzen wir es zusammen — es geht um Objekte, um Typkonvertierung und um die moderne Syntax, die den Umgang damit erheblich angenehmer macht.