Objekte, Typkonvertierung und moderne Syntax

JavaScript — Objekte und moderne Syntax

0:00 Bisher haben wir mit einzelnen Werten gearbeitet: eine Zahl, ein Text, ein Ja oder Nein. In der Praxis reicht das selten. Ein Beet hat einen Namen, eine Fläche, ein Pflanzdatum und einen Zustand — und all das gehört zusammen. In diesem Modul lernen Sie, Daten zu strukturieren. Wir bauen Objekte, schicken sie als Text durch die Welt, arbeiten mit Datumswerten und mit den beiden Arten von Nichts, die JavaScript kennt.

0:26 Zwei Punkte aus diesem Modul erzeugen erfahrungsgemäß später die meisten Fehler. Ich werde beide besonders markieren.

Strukturierte Daten

0:33 Acht Kapitel — das ist das umfangreichste Modul des ersten Tages, und das aus gutem Grund. Wir beginnen mit Objekten selbst, gehen dann zu JSON, dem Format, in dem Daten zwischen Systemen reisen. Datum und Uhrzeit sind ein eigenes Kapitel, weil sie überraschend viele Fallen bergen. Danach die feine Unterscheidung zwischen null und undefined, Klassen als Vorlage für gleichartige Objekte, Typkonvertierung und die modernen Syntaxmuster, die Sie in jedem aktuellen Projekt sehen.

1:01 Zum Schluss ein Blick auf reguläre Ausdrücke — mit Maß.

Objekte

1:05 Beginnen wir mit dem Baustein, der alles zusammenhält. Objekte sind schnell erklärt — bis auf eine Eigenschaft, die fast alle beim ersten Mal überrascht. Auf die kommen wir am Ende dieses Kapitels, und sie ist es wert, dass man sie einmal selbst erlebt. Ein Objekt bündelt zusammengehörende Werte unter benannten Eigenschaften. Denken Sie an ein Formular: Es hat Felder mit Beschriftungen, und in jedem Feld steht ein Wert.

1:31 Genau so ist ein Objekt aufgebaut — Name, Doppelpunkt, Wert, und das Ganze in geschweiften Klammern. Diese Schreibweise heißt Objektliteral, weil das Objekt buchstäblich so im Code steht, wie es gemeint ist. Sie ist der mit Abstand häufigste Weg, ein Objekt zu erzeugen, und sie ist bewusst leichtgewichtig: keine Vorlage, keine Deklaration, keine Ankündigung.

1:53 Sie schreiben einfach hin, welche Daten zusammengehören. Zwei Wege führen an eine Eigenschaft heran, und der Unterschied ist wichtiger, als er aussieht. Die Punktschreibweise ist der Normalfall — kurz, lesbar, im Editor gut unterstützt. Die Klammerschreibweise wirkt zunächst umständlich, kann aber etwas, das die andere nicht kann: Sie nimmt den Eigenschaftsnamen aus einer Variablen entgegen.

2:16 Sehen Sie sich die letzten Zeilen an — dort steht der Feldname nicht im Code, sondern wird zur Laufzeit entschieden. Das brauchen Sie, sobald Daten dynamisch sind, etwa wenn ein Nutzer auswählt, welches Feld angezeigt wird. Und Sie brauchen es bei Namen mit Leerzeichen, die als Punktzugriff gar nicht schreibbar wären. Objekte sind offen: Eigenschaften lassen sich jederzeit ergänzen, ändern und löschen. Das ist enorm flexibel und hat eine Schattenseite, die den zweiten Punkt erklärt.

2:45 Greifen Sie auf eine Eigenschaft zu, die es nicht gibt, bekommen Sie keinen Fehler — Sie bekommen undefined. Die Sprache geht davon aus, dass Sie wissen, was Sie tun. In der Praxis heißt das: Ein Tippfehler im Eigenschaftsnamen bleibt unbemerkt, und der Fehler taucht erst viel später auf, an ganz anderer Stelle. Wenn Sie wirklich wissen wollen, ob eine Eigenschaft existiert, gibt es dafür eine eigene Prüffunktion.

3:09 Die Frage „ist das undefined oder gibt es das gar nicht?" beantwortet nur sie. Das ist der Punkt, den ich angekündigt habe — schauen Sie genau hin. In der zweiten Zeile sieht es aus, als würde ein Objekt kopiert. Wird es aber nicht. Beide Variablen zeigen auf dasselbe Objekt, so wie zwei Zettel mit derselben Adresse darauf.

3:29 Ändern Sie etwas über den einen Namen, sehen Sie es über den anderen ebenfalls — und genau das steht in der Ausgabe. Eine echte Kopie entsteht erst mit der Drei-Punkt-Schreibweise weiter unten. Diese Referenz-Semantik ist keine Eigenart von JavaScript, sie gilt in vielen Sprachen. Aber sie ist die Ursache für eine ganze Familie schwer auffindbarer Fehler.

3:51 Führen Sie beides selbst vor: eine Änderung, die in beiden Variablen sichtbar wird, und eine, die nur eine der beiden betrifft. Der Unterschied zwischen diesen zwei Zeilen ist einer der wertvollsten Aha-Momente des ganzen Kurses. Wer ihn einmal produziert hat, erkennt später in echtem Code sofort, wo eine ungewollte Fernwirkung entstehen kann.

4:10 Zum Prüfen, ob eine Eigenschaft überhaupt existiert, hilft die erwähnte Prüffunktion — sie unterscheidet sauber zwischen „steht auf undefined" und „gibt es nicht". Der erste Punkt ist die direkte Folge aus dem Codebeispiel und der häufigste Objektfehler überhaupt: Eine Zuweisung kopiert nichts. Der zweite ist der stille Tippfehler, der als undefined durchrutscht — und deshalb erst drei Funktionsaufrufe später als merkwürdiges Verhalten auffällt.

4:36 Zum dritten: const schützt nur, welches Objekt in der Variablen liegt; der Inhalt bleibt vollständig änderbar. Das haben wir im letzten Modul geklärt, und es wird trotzdem regelmäßig vergessen. Und der letzte Rat: Statt Eigenschaften zu löschen, ist es meist klarer, ein neues Objekt in der gewünschten Form zu bauen. Das Muster dafür sehen wir später in diesem Modul.

JSON-Grundlagen

4:58 Jetzt geht es darum, Daten aus dem Programm herauszubringen — in eine Datei, über das Netz, in ein anderes System. Dafür gibt es ein Format, das inzwischen praktisch überall verstanden wird. Und ein Missverständnis, das sich hartnäckig hält. Ein Satz trägt dieses ganze Kapitel: Ein JavaScript-Objekt ist ein Wert im Programm, JSON ist Text. Die Schreibweise sieht fast identisch aus, und genau das führt zur Verwechslung.

5:24 Aber JSON ist strenger — und vor allem ist es sprachunabhängig. Ein Python-Programm, ein Java-Dienst, eine Datenbank: Alle können JSON lesen, weil es eben nur Text nach klaren Regeln ist. Denken Sie an den Unterschied zwischen einem Möbelstück und dem Bauplan im Paket. Das eine steht bei Ihnen im Zimmer, das andere lässt sich verschicken.

5:44 Beim Auspacken müssen Sie es wieder zusammensetzen — und dabei geht manches verloren. Zwei Funktionen, zwei Richtungen. Die eine macht aus Ihrem Objekt Text, die andere aus Text wieder ein Objekt. Achten Sie auf den mittleren Aufruf mit den zusätzlichen Argumenten: Die Zahl am Ende gibt die Einrückung an und verwandelt eine unleserliche Zeile in eine ordentlich formatierte Struktur.

6:07 Das ist beim Debuggen Gold wert. Die letzte Zeile zeigt die andere Seite der Medaille — das Einlesen kann scheitern, und zwar mit einem Fehler, der Ihr Programm abbricht. Bei fremden Daten ist das kein Sonderfall, sondern der Normalfall. Wie man damit umgeht, sehen wir im Modul zur Fehlerbehandlung. Das Prinzip hinter dieser Aufstellung ist einfach: JSON kennt nur Daten, kein Verhalten und keine Sprachbesonderheiten. Eine Funktion ist Verhalten, sie fällt weg.

6:35 Undefined ist eine JavaScript-Eigenheit ohne Entsprechung im Format, fällt ebenfalls weg — und zwar stillschweigend, ohne Warnung. Das Datum ist der interessanteste Fall: Es überlebt als Text, aber eben nur als Text. Wandeln Sie zurück, haben Sie eine Zeichenkette und kein Datumsobjekt mehr. Rechnen können Sie damit nicht. Diesen Rückweg müssen Sie selbst organisieren, und in echten Projekten ist genau das eine wiederkehrende Aufgabe.

7:02 Diese Aufgabe hat einen kleinen Vorhersage-Teil, und der ist der eigentliche Punkt. Bauen Sie ein Objekt mit einem Datum und einer Funktion darin. Sagen Sie vorher an, welche Felder den Weg durch JSON nicht überleben werden. Und dann belegen Sie es an der Ausgabe. Wer richtig getippt hat, hat die Tabelle verstanden. Wer danebenlag, hat gerade den wertvolleren Lerneffekt gehabt. Für die lesbare Ausgabe nutzen Sie den Aufruf mit Einrückung — das werden Sie später ohnehin ständig brauchen.

7:32 Die Datumserwartung steht nicht ohne Grund an erster Stelle — sie kostet in echten Projekten regelmäßig Zeit. Der zweite Punkt ist reine Formatstrenge: JSON erlaubt ausschließlich doppelte Anführungszeichen, auch um die Feldnamen. Wer aus dem JavaScript-Alltag einfache Anführungszeichen mitbringt, produziert ungültiges JSON, das die Gegenstelle ablehnt.

7:53 Punkt drei ist eine Haltungsfrage: Fremde Daten sind grundsätzlich verdächtig, und das Einlesen kann fehlschlagen. Und der letzte Punkt fasst das Kapitel zusammen: JSON und Objektliteral sind sich ähnlich, aber nicht dasselbe. Verhalten reist nicht mit.

Datum und Uhrzeit

8:08 Nun zu einem Thema, das in jeder Programmiersprache für Ärger sorgt. Zeit ist nämlich viel komplizierter, als der Blick auf die Uhr vermuten lässt. Und JavaScript hat obendrein eine Eigenheit eingebaut, die seit dreißig Jahren Menschen stolpern lässt. Ein Datumsobjekt ist genau genommen kein Datum, sondern ein Zeitpunkt — mit Uhrzeit, bis auf die Millisekunde.

8:30 Intern ist es sogar noch schlichter: Es ist eine einzige große Zahl, nämlich die Anzahl Millisekunden seit dem ersten Januar 1970, null Uhr, koordinierte Weltzeit. Dieser Nullpunkt heißt Epochenbeginn und stammt aus der Unix-Welt. Alles, was Sie an Kalenderinformation sehen — Jahr, Monat, Tag —, wird aus dieser einen Zahl berechnet, unter Berücksichtigung von Zeitzone und Kalenderregeln.

8:54 Wenn Sie sich das merken, verstehen Sie hinterher die meisten Merkwürdigkeiten von selbst. Hier ist sie, die berühmte Falle: Der Monat zählt ab null. Die Zwei in der Mitte bedeutet März, nicht Februar. Der Tag des Monats dagegen zählt ganz normal ab eins — eine Inkonsistenz, die niemand mehr repariert, weil zu viel Code darauf aufbaut.

9:14 Rechnen Sie fest damit, dass Ihnen dieser Fehler mindestens einmal passiert; er sieht in der Ausgabe völlig plausibel aus und liegt trotzdem einen Monat daneben. Ansonsten sehen Sie drei Wege der Erzeugung: aktueller Zeitpunkt, aus Text, aus Einzelteilen. Und ganz unten die interne Millisekundenzahl — die brauchen Sie, sobald Sie mit Zeiträumen rechnen wollen.

9:36 Der Kern des Problems: Ein Zeitpunkt ist eindeutig, seine Darstellung nicht. Derselbe Moment heißt in Berlin anders als in New York, und je nach Jahreszeit verschiebt sich die Differenz auch noch. Dazu kommen Kalendersysteme und regionale Formate — bei einem Datum mit den Zahlen drei und vier ist selbst für Menschen nicht klar, ob der März oder der April gemeint ist.

9:57 Und Datumswerte aus Zeichenketten werden je nach Schreibweise unterschiedlich gedeutet, was zu Verschiebungen um einen ganzen Tag führen kann. Es gibt inzwischen eine neuere Schnittstelle namens Temporal, die vieles davon sauber löst. Das alte Datumsobjekt müssen Sie trotzdem lesen können — es steckt in unzähligen Projekten.

10:16 Legen Sie ein Datum für den fünfzehnten Februar an — und zwar korrekt, also mit dem Monatswert, den die Sprache dafür erwartet. Die Prüffunktion bestätigt ihn Ihnen anschließend. Klingt trivial, ist aber genau die Stelle, an der man in der Praxis danebengreift. Und dann noch ein Zusatz, der sich lohnt: Geben Sie denselben Zeitpunkt zusätzlich in lokalisierter Form aus und vergleichen Sie die Darstellungen.

10:39 Sie sehen dann unmittelbar, dass ein Zeitpunkt und seine Anzeige zwei verschiedene Dinge sind — die Einsicht aus der vorigen Folie, praktisch belegt. Der nullbasierte Monat führt die Liste an, weil er der einzige Fehler ist, der garantiert jedem passiert. Der zweite Punkt ist tückischer: Zeitzonen zu ignorieren funktioniert genau so lange, bis jemand in einer anderen Zeitzone das Programm benutzt — und dann ist der angezeigte Tag um eins verschoben.

11:05 Punkt drei ist eine Entwurfsentscheidung mit Folgen: Wer Datumswerte als Zeichenkette ablegt, kann später nicht mehr rechnen und sortieren, ohne jedes Mal umzuwandeln. Und der letzte: Zeiträume ermittelt man über die Millisekundenzahlen, nicht durch Abziehen von Kalendertagen — sonst kippt es spätestens bei der Sommerzeitumstellung.

null, undefined und nullish

11:24 Jetzt kommt der zweite Punkt, den ich zu Beginn angekündigt habe — praktisch der wichtigste des ganzen Moduls. Es geht um zwei Arten von Nichts und um zwei Operatoren, die fast dasselbe tun. Fast. Zwei Arten von Nichts, und die Unterscheidung hat einen praktischen Sinn. Undefined bedeutet: Hier wurde nie ein Wert zugewiesen — meistens ist das ein Zustand, kein Entschluss.

11:47 Null dagegen ist die bewusst gesetzte Leere: Jemand hat entschieden, dass hier nichts steht. Der Unterschied zwischen „noch nicht ausgefüllt" und „ausdrücklich leer" kennt jeder aus Formularen. Und dann der Begriff, um den sich alles Weitere dreht: Nullish sind genau diese beiden Werte — und sonst keiner. Eine Null, ein false, eine leere Zeichenkette gehören ausdrücklich nicht dazu. Merken Sie sich diese Grenze, sie ist gleich entscheidend.

12:15 Zwei Operatoren, die zusammengehören. Das Fragezeichen vor dem Punkt sagt sinngemäß: Wenn hier nichts ist, brich ab und liefere undefined, statt einen Fehler zu werfen. Ohne diese Absicherung stürzt der Zugriff auf eine Eigenschaft von undefined ab — ein Klassiker in jeder Anwendung, die Daten von außen bekommt. Der spannende Teil steht unten.

12:35 Dieselbe Situation, zweimal, mit unterschiedlichem Ergebnis: Der Oder-Operator ersetzt die Null durch den Ersatzwert, weil Null als unwahr gilt. Der doppelte Fragezeichen-Operator lässt sie stehen, weil sie eben nicht nullish ist. Eine Null ist ein gültiger Zählerstand — und die falsche Wahl macht daraus stillschweigend eine Sieben.

12:56 Diese Tabelle ist die Landkarte zur vorigen Folie. Fünf Werte gelten als unwahr, aber nur zwei davon sind nullish. Der doppelte Fragezeichen-Operator greift bei den ersten beiden, der Oder-Operator bei allen fünf. Daraus folgt eine Entscheidungsregel, die Sie ab sofort anwenden können: Fragen Sie sich, ob Null, false oder die leere Zeichenkette in Ihrem Fall gültige Werte sind.

13:18 Wenn ja — und das ist bei Zählern, Preisen und Schaltern fast immer so —, dann brauchen Sie den nullish-Operator. Wenn Sie nur einen fehlenden Wert abfangen wollen, ebenfalls. Der Oder-Operator als Fallback ist inzwischen fast immer die schlechtere Wahl. Bauen Sie den Fall nach, der in echten Anwendungen Geld kostet: ein Zähler mit dem gültigen Wert Null. Ihre Lösung muss die Null liefern und nicht den Ersatzwert.

13:42 Und dann der eigentlich lehrreiche Teil: Prüfen Sie dieselbe Stelle einmal mit dem einen und einmal mit dem anderen Operator, und schauen Sie sich beide Ausgaben nebeneinander an. Der Unterschied ist ein einziges Zeichen im Quelltext und ein grundlegend anderes Verhalten im Programm. Genau so etwas findet man in einem Code-Review nur, wenn man weiß, wonach man sucht.

14:02 Der erste Punkt ist der teuerste dieses Moduls: Der Oder-Operator als Fallback überschreibt die gültige Null. In einem Warenkorb mit null Artikeln, bei einem Rabatt von null Prozent, bei einer Temperatur von null Grad — überall dort wird still etwas Falsches eingesetzt. Zweitens die alte typeof-Kuriosität bei null, die aus historischen Gründen erhalten bleibt und für Typprüfungen unbrauchbar ist.

14:25 Drittens: null und undefined synonym zu verwenden verwischt die Absicht, die Sie sich gerade erarbeitet haben. Und der letzte Punkt ist eine Warnung vor Übereifer — die optionale Verkettung überall zu setzen, schaltet echte Fehler stumm. Dann läuft alles, nur eben falsch.

Klassen

14:42 Weiter mit Klassen. Wir bleiben hier bewusst auf Grundlagenniveau: Es geht darum, eine Vorlage für gleichartige Objekte zu bauen und zu wissen, was der Code bedeutet, wenn Sie ihm begegnen. Vererbung und tiefere Objektorientierung sind ein eigenes Thema. Eine Klasse ist eine Vorlage — denken Sie an einen Ausstecher für Plätzchen. Der Ausstecher selbst ist kein Plätzchen, er legt nur die Form fest.

15:06 Erst wenn Sie ihn benutzen, entsteht ein konkretes Exemplar. Genau das macht das Schlüsselwort new: Es erzeugt aus der Vorlage eine Instanz. Beschrieben wird in der Klasse zweierlei — welche Daten so ein Objekt trägt und welches Verhalten es kennt. Diese Zusammenführung ist der eigentliche Gewinn: Die Information und die Funktionen, die damit umgehen, stehen an einer Stelle statt verteilt über das Programm.

15:30 Vier Bausteine stecken in diesem kurzen Beispiel. Ganz oben ein öffentliches Feld mit Vorbelegung — das spart eine Zuweisung im Konstruktor. Darunter ein Feld mit einer Raute davor: Das Zeichen macht es privat, es ist von außen schlicht nicht erreichbar. Der Konstruktor ist die Funktion, die beim Erzeugen läuft; das Wort this darin verweist auf das Objekt, das gerade entsteht.

15:52 Und unten eine Methode — eine Funktion, die zur Klasse gehört und auf deren Daten zugreift. Beachten Sie die Schreibweise des Klassennamens: großgeschrieben, im Unterschied zu allen anderen Bezeichnern. Das ist Konvention, aber eine, an die sich alle halten. Der Unterschied zwischen öffentlich und privat ist eine Frage der Verantwortung. Öffentliche Felder darf jeder lesen und ändern — bequem, aber Sie geben die Kontrolle ab.

16:18 Private Felder bleiben im Inneren der Klasse; nur die Methoden der Klasse selbst kommen daran. Damit können Sie garantieren, dass ein Wert bestimmten Regeln folgt. Die dritte Kategorie sind statische Mitglieder: Sie gehören der Klasse selbst, nicht einem einzelnen Objekt. Das klingt abstrakt, ist Ihnen aber längst begegnet — die Prüffunktionen und Umwandlungsfunktionen, die wir bisher benutzt haben, sind genau das.

16:43 Man ruft sie am Namen der Klasse auf, ohne je eine Instanz erzeugt zu haben. Modellieren Sie ein Beet als Klasse und erzeugen Sie zwei Instanzen mit new. Beide sollen über eine Methode eine korrekte Beschriftung liefern — damit sehen Sie, dass jede Instanz ihre eigenen Daten trägt, obwohl beide dieselbe Vorlage benutzen.

17:02 Der dritte Teil ist der interessante: Versuchen Sie, von außen auf das private Feld zuzugreifen. Das schlägt fehl, und zwar hart, mit einem Fehler statt einer freundlichen Warnung. Diese Härte ist Absicht — Privatheit, die man umgehen kann, ist keine. Ein öffentliches Feld mit Vorbelegung spart Ihnen übrigens eine Zeile im Konstruktor.

17:23 Das vergessene new ist der Einstiegsfehler — statt einer Instanz bekommen Sie etwas, mit dem Sie nichts anfangen können, und die Folgefehler zeigen an ganz andere Stellen. Der Zugriff auf private Felder von außen ist, wie gesagt, ein echter Fehler und keine Warnung; das ist gut so, überrascht aber, wenn man es aus anderen Sprachen anders kennt.

17:42 Der kleingeschriebene Klassenname bricht eine Konvention, an der sich Leser orientieren — und Konventionen sind billig einzuhalten. Und der letzte Punkt ist ein Architekturhinweis: Vererbung ist ein mächtiges, aber teures Werkzeug. Zwei eigenständige Klassen sind häufig die klarere Lösung.

Typkonvertierung

17:59 Jetzt zu einem Thema, bei dem JavaScript einen zweifelhaften Ruf hat. Die Sprache wandelt Typen nämlich gern selbstständig um — und ihre Entscheidungen sind nicht immer die, die man erwartet hätte. Die Kernbotschaft nehme ich vorweg: Wenn der Typ zählt, wandeln Sie selbst um. Zwei Wege führen von einem Typ zum anderen. Explizit heißt: Sie sagen es hin.

18:21 Es gibt Funktionen für Text, Zahl, Wahrheitswert und große Ganzzahl, und wenn Sie eine davon aufrufen, ist für jeden Leser klar, was passieren soll. Implizit heißt: JavaScript macht es von selbst, je nachdem, welcher Operator gerade im Spiel ist. Das ist bequem und die Quelle unzähliger Spott-Artikel über die Sprache. Fair ist: Die Regeln sind konsistent, sie sind nur nicht intuitiv. Und deshalb lautet die praktische Empfehlung, sich nicht darauf zu verlassen, sondern die Absicht hinzuschreiben.

18:52 Drei Dinge lohnen hier den genauen Blick. Erstens: Der Versuch, einen nicht-numerischen Text in eine Zahl zu wandeln, wirft keinen Fehler, sondern liefert NaN — „keine Zahl". Das ist ein gültiger Wert vom Typ Zahl, und er steckt jede weitere Rechnung an. Zweitens die Zeile mit dem Text „false": Sie ergibt wahr, weil die Zeichenkette nicht leer ist.

19:13 Der Inhalt spielt keine Rolle. Und drittens der Block ganz unten — dieselben Funktionen mit new davor erzeugen Objekte statt einfacher Werte. Das brauchen Sie nie, es verhält sich unerwartet, und Sie sollten es nur erkennen können, wenn es Ihnen in fremdem Code begegnet. Diese Liste ist erfreulich kurz, und genau das ist die Botschaft: Es sind nur diese wenigen Werte, die als unwahr gelten.

19:37 Alles andere ist wahr — und mit alles andere meine ich wirklich alles: jede nichtleere Zeichenkette, jedes Objekt, auch ein leeres, jedes Array, auch ein leeres. Wer diese kurze Liste im Kopf hat, kann jede Bedingung in JavaScript korrekt vorhersagen. Die letzte Zeile ist die wichtigste Warnung: Die Zeichenkette mit dem Wort „false" darin ist nicht leer und damit wahr.

20:00 Genau dieser Fall trifft Sie, sobald Werte aus Konfigurationsdateien oder Umgebungsvariablen kommen — dort ist alles Text. Nehmen Sie eine Eingabe, die keine Zahl ist, und behandeln Sie sie ordentlich: erkennen, dass die Umwandlung fehlgeschlagen ist, und mit einer eigenen Meldung antworten, statt weiterzurechnen. Der Unterschied ist erheblich — rechnen Sie weiter, breitet sich NaN durch Ihr ganzes Programm aus und taucht am Ende an einer Stelle auf, die mit der Ursache nichts zu tun hat.

20:28 Ein Hinweis zur Prüffunktion: Nehmen Sie die Variante an der Zahlen-Klasse, nicht die gleichnamige globale Funktion. Die globale wandelt vorher noch selbst um und liefert dadurch überraschende Ergebnisse. Der Text mit dem Wort „false" ist der Klassiker und begegnet Ihnen garantiert, sobald Konfiguration ins Spiel kommt. Der zweite Punkt beschreibt eine Kettenreaktion: NaN steckt an.

20:50 Jede Rechnung damit ergibt wieder NaN, und die Spur zurück zur Ursache kann lang sein — deshalb prüft man früh, nicht spät. Die Verwechslung der beiden Prüffunktionen ist subtil und liefert genau dann falsche Antworten, wenn es darauf ankommt. Und der letzte Punkt ist die Zusammenfassung des Kapitels: Sich auf die implizite Umwandlung zu verlassen, funktioniert oft — aber wenn es schiefgeht, sucht man lange.

Moderne Syntaxmuster

21:15 Jetzt zu den Schreibweisen, die modernen JavaScript-Code auf den ersten Blick von altem unterscheiden. Sie sparen nicht nur Tipparbeit — sie drücken Absichten aus, für die es früher keine kurze Form gab. Und ein Zeichen darin hat zwei völlig verschiedene Bedeutungen. Zwei Werkzeuge stecken in diesem Kapitel. Die Destrukturierung packt aus: Sie entnimmt Werte aus einem Objekt oder Array und legt sie in eigene Variablen — statt fünf Zeilen mit fünf Zuweisungen schreiben Sie eine.

21:44 Das zweite ist die Drei-Punkt-Schreibweise, und die ist doppeldeutig. Steht sie links, beim Entgegennehmen, sammelt sie alles Übrige ein — das nennt man Rest. Steht sie rechts, beim Erzeugen, breitet sie vorhandene Werte aus — das ist der Spread. Dieselben drei Punkte, entgegengesetzte Richtung, und die Position entscheidet.

22:03 Wer das einmal verstanden hat, liest modernen Code deutlich flüssiger. Vier Varianten in einem Block, und jede löst ein eigenes Alltagsproblem. Die erste Zeile ist der Normalfall — zwei Werte, zwei Variablen. Die zweite benennt beim Auspacken um, was Sie brauchen, sobald ein Feldname mit einer bestehenden Variablen kollidiert.

22:24 Die dritte setzt einen Standardwert für den Fall, dass das Feld gar nicht existiert — praktisch bei allem, was von außen kommt. Die vierte sammelt den ganzen Rest in ein neues Objekt. Und unten dasselbe für Arrays, mit einem Unterschied: Dort entscheidet die Position statt des Namens. Die auffällige Lücke zwischen den Kommas überspringt bewusst einen Eintrag.

22:46 Hier sehen Sie das Muster, das modernes JavaScript prägt wie kaum ein anderes: Statt ein bestehendes Objekt zu verändern, bauen Sie ein neues, das die alten Werte plus eine Ergänzung enthält. Die Ausgabe belegt es — das Ausgangsobjekt weiß nichts von der Erweiterung. Warum ist das so beliebt? Weil es die Fernwirkung ausschließt, die wir im ersten Kapitel gesehen haben.

23:07 Wenn niemand ein Objekt heimlich verändert, muss auch niemand damit rechnen. Das Gleiche funktioniert mit Arrays, wie die letzten Zeilen zeigen. Eine Einschränkung merken Sie sich für die Stolpersteine gleich: Die Kopie reicht nur eine Ebene tief. Leiten Sie aus einem bestehenden Objekt ein erweitertes ab, das ein zusätzliches Feld trägt — und weisen Sie nach, dass das Ausgangsobjekt unverändert geblieben ist.

23:31 Dieser Nachweis ist der Kern der Übung; er unterscheidet dieses Muster von dem, was viele reflexhaft täten. Und dann noch eine kleine Zugabe: Destrukturieren Sie anschließend zwei Felder aus dem Ergebnis heraus, eines davon mit neuem Namen. Damit haben Sie beide Werkzeuge dieses Kapitels in einem Durchgang angewendet — und genau so werden sie in echtem Code auch benutzt, nämlich gemeinsam.

23:54 Der erste Punkt ist der wichtigste und wird oft übersehen: Die Drei-Punkt-Kopie ist flach. Ein verschachteltes Objekt darin wird nicht mitkopiert — es bleibt geteilt, mit allen Fernwirkungen, die wir kennen. Für tiefe Kopien braucht es andere Mittel. Der zweite Punkt ist eine reine Regel: Der Rest muss an letzter Stelle stehen, sonst gibt es einen Syntaxfehler.

24:15 Beim Destrukturieren von Arrays verzählt man sich leicht um eine Position, besonders bei übersprungenen Einträgen. Und der letzte ist die Wiederkehr unseres Fallback-Themas in Zuweisungsform: Auch hier überschreibt die Oder-Variante gültige Nullwerte.

Reguläre Ausdrücke

24:30 Zum Abschluss ein Werkzeug mit zweifelhaftem Ruf: mächtig, unverzichtbar — und berüchtigt für Ausdrücke, die niemand mehr lesen kann, nicht einmal ihr Autor eine Woche später. Deshalb behandeln wir es mit Maß. Ein regulärer Ausdruck beschreibt kein konkretes Wort, sondern ein Muster — etwa „drei Ziffern, dann ein Bindestrich, dann Buchstaben".

24:51 Notiert wird er zwischen Schrägstrichen, oder alternativ über einen Konstruktor, wenn das Muster erst zur Laufzeit entsteht. Hinter dem schließenden Schrägstrich können Flags stehen, kleine Buchstaben, die das Verhalten steuern: Groß- und Kleinschreibung ignorieren, alle Treffer statt nur den ersten, mehrzeilig arbeiten.

25:10 Diese kompakte Notation ist Segen und Fluch zugleich — sie ist unschlagbar dicht und dadurch schnell unlesbar. Ein Muster mit drei Zeichen ist ein Geschenk, eines mit dreißig ist eine Hypothek. Drei typische Anwendungen. Ganz oben die einfachste Frage: Kommt das Muster vor, ja oder nein — und die Variante darunter mit dem Flag, das Groß- und Kleinschreibung ignoriert.

25:32 In der Mitte wird es interessant: eine benannte Gruppe. Der eingeklammerte Teil bekommt einen Namen, und über diesen Namen greifen Sie später auf den Teiltreffer zu. Das ist enorm viel lesbarer als die früher übliche Nummerierung. Unten wird ersetzt — alle Nicht-Ziffern verschwinden, übrig bleibt die Zahl. Und die letzte Zeile ist ein Sicherheitswerkzeug: Sie entschärft Sonderzeichen, wenn ein Muster aus fremdem Text zusammengesetzt wird.

25:59 Für Suchen, Prüfen, Extrahieren und Umformen von Text gibt es kein stärkeres Werkzeug — das ist unbestritten. Benannte Gruppen haben die Lesbarkeit zudem deutlich verbessert. Aber die Bewertung fällt zweiseitig aus, und das ist ehrlicher als jede Begeisterung: Mit der Länge des Musters sinkt die Lesbarkeit rapide, und zwar schneller, als man beim Schreiben glaubt.

26:20 Deshalb die praktische Empfehlung: Für einfache Fälle reichen die eingebauten Textmethoden — enthält, beginnt mit, endet mit, alles ersetzen. Sie sind auf einen Blick verständlich, jeder im Team liest sie sofort. Nehmen Sie das einfachste Werkzeug, das die Aufgabe löst. Zwei Teile. Erstens: Ziehen Sie mit einer benannten Gruppe eine Nummer aus einer Beschriftung heraus und greifen Sie über den Namen darauf zu.

26:45 Zweitens — und das ist der Teil mit dem größten Praxiswert: Entschärfen Sie einen Suchbegriff, der aus einer Nutzereingabe stammt, bevor Sie ihn in ein Muster einsetzen. Warum, zeigt ein einziges Zeichen: Ein Punkt bedeutet in einem Muster nicht „Punkt", sondern „irgendein Zeichen". Ohne Entschärfung sucht Ihr Programm also etwas ganz anderes als das, was der Nutzer eingegeben hat.

27:08 Nutzereingaben ungeprüft in ein Muster einzusetzen, steht nicht ohne Grund an erster Stelle — das ist nicht nur ein Verhaltensfehler, sondern je nach Muster auch ein Sicherheitsthema. Das vergessene Flag für alle Treffer ist der Grund für die Beobachtung „es ersetzt nur das erste Vorkommen", die wir schon bei den Zeichenketten hatten.

27:26 Der Punkt als Platzhalter ist die häufigste Fehldeutung überhaupt — wer ein wörtliches Punktzeichen meint, muss es markieren. Und der letzte Punkt fasst die Bewertung zusammen: Ein unleserliches Muster dort, wo eine einfache Textmethode gereicht hätte, ist kein Können, sondern eine Bürde für alle Nachfolger.

Daten haben jetzt Struktur

27:43 Drei Sätze aus diesem Modul werden Sie noch oft brauchen. Objekte werden per Referenz übergeben — eine Zuweisung kopiert nichts, und wer das vergisst, baut Fernwirkungen ein, die er nicht sucht. JSON ist Text, und deshalb überleben Funktionen, undefined und Datumsobjekte den Weg nicht. Und der Fallback-Operator mit den zwei Fragezeichen greift nur bei null und undefined, während die Oder-Variante jeden unwahren Wert ersetzt — inklusive der gültigen Null.

28:10 Damit haben Ihre Daten Struktur. Im nächsten Modul bringen wir sie in Bewegung: Es geht um Ausdrücke, Operatoren und Bedingungen.