Verzweigungen, Schleifen und Eingabeprüfung

JavaScript — Verzweigungen und Schleifen

0:00 Im letzten Modul hat Ihr Programm gelernt zu entscheiden. Eine Entscheidung allein reicht aber selten. Echte Software wiederholt Dinge — sie geht Listen durch, prüft Einträge, sucht Treffer. Und sie muss dem misstrauen, was von außen hereinkommt. Genau darum geht es hier. Wir sehen uns kompakte Schreibweisen für Verzweigungen an, dann die verschiedenen Schleifenformen und ihre Steuerung.

0:23 Das letzte Kapitel führt alles zusammen: Dort entsteht zum ersten Mal ein kleines, vollständiges Programm, das mit einem Menschen redet — und ihm nicht blind glaubt.

Wiederholen und prüfen

0:33 Fünf Kapitel, und sie bauen aufeinander auf. Zwei kompakte Formen der Verzweigung stehen am Anfang: der ternäre Operator für die Wahl zwischen zwei Werten und die switch-Anweisung für einen Wert gegen viele Möglichkeiten. Dann der Überblick über die Schleifenarten — es sind fünf, und die Wahl der richtigen erspart die meisten Fehler von vornherein.

0:52 Danach die Steuerung mit vorzeitigem Ausstieg und übersprungenen Durchläufen. Und zum Schluss die Eingabeprüfung, in der alles zusammenkommt.

Der ternäre Operator

1:01 Fangen wir mit einer Schreibweise an, die polarisiert. Manche finden sie elegant, andere unleserlich — und beide haben recht, je nachdem, wie man sie einsetzt. Der Schlüssel liegt in einer Unterscheidung, die man einmal klar haben sollte. Der Name klingt sperriger, als die Sache ist: ternär heißt dreiteilig, weil drei Teile beteiligt sind — die Bedingung, der Wert für den wahren Fall und der Wert für den falschen.

1:26 Getrennt werden sie durch Fragezeichen und Doppelpunkt, und man liest es fast wie eine Frage mit zwei Antwortmöglichkeiten. Der wichtigste Satz steht am Ende der Definition: Es ist ein Ausdruck. Er liefert also einen Wert und lässt sich überall dort einsetzen, wo ein Wert stehen darf — in einer Zuweisung, in einem Funktionsaufruf, mitten in einem Text.

1:46 Genau das kann eine if-Anweisung nicht. Der Vergleich zeigt beide Fassungen. Oben vier Zeilen mit einer Variablen, die erst leer angelegt und dann in zwei Zweigen befüllt wird. Unten dieselbe Logik in einer Zeile — und mit einem Zusatzgewinn: Der Wert steht sofort fest, deshalb kann die Variable mit const angelegt werden statt mit let.

2:06 Das ist mehr als Kosmetik, es ist eine Zusage an den Leser, dass sich hier nichts mehr ändert. Die letzte Zeile zeigt die zweite Stärke: Weil es ein Ausdruck ist, funktioniert er auch mitten in einem Template-Literal. Für so etwas müsste man mit if den ganzen Text auseinanderreißen. Die Abgrenzung ist erfreulich klar. Der ternäre Operator passt, wenn Sie zwischen genau zwei Werten wählen — nicht mehr, nicht weniger.

2:31 Sobald mehrere Anweisungen ausgeführt werden sollen oder mehr als zwei Zweige nötig sind, ist die if-Anweisung das richtige Werkzeug. Der Satz in der Mitte fasst es am besten: Der ternäre Operator liefert einen Wert, if steuert die Ausführung. Zwei verschiedene Aufgaben, zwei verschiedene Werkzeuge. Und der letzte Punkt ist eine deutliche Warnung: Verschachtelte ternäre Ausdrücke sind syntaktisch völlig in Ordnung — und in der Praxis fast immer unlesbar.

2:58 Da ist eine else-if-Kette klar überlegen. Nehmen Sie eine vierzeilige Zuweisung mit if und else und machen Sie einen Ausdruck daraus, der für beide Fälle dasselbe liefert wie zuvor. Der eigentliche Lernpunkt steckt in der Formulierung des Lernziels: Sie sollen erkennen, wann eine Verzweigung in Wahrheit gar keine Verzweigung ist, sondern eine Wertauswahl.

3:18 Das ist ein Blick, der sich schulen lässt. Und behalten Sie den Hinweis im Kopf: Wenn Sie den fertigen Ausdruck nicht mehr in einem Blick erfassen, gehört er zurück in ein if. Kürze ist ein Mittel, kein Ziel. Die Verschachtelung steht zu Recht an erster Stelle — zwei ineinandergeschobene ternäre Ausdrücke sind der zuverlässigste Weg, einen Kollegen zu verlieren.

3:39 Der zweite Punkt scheitert schon an der Sprache: Mehrere Anweisungen passen dort nicht hinein, weil es eben ein Ausdruck ist und keine Anweisungsliste. Punkt drei ist die Haltung dahinter — Kürze und Lesbarkeit sind nicht dasselbe, und wo sie sich widersprechen, gewinnt die Lesbarkeit. Und der letzte ist rein mechanisch: Der else-Zweig ist nicht optional. Ohne Doppelpunkt und zweiten Wert gibt es keinen ternären Ausdruck.

Die switch-Anweisung

4:04 Weiter mit einer Konstruktion, die es in fast jeder Programmiersprache gibt — und die in JavaScript eine Eigenheit hat, über die schon Generationen von Entwicklern gestolpert sind. Wir zeigen sie bewusst, statt sie zu verschweigen. Die Idee ist eine Weiche: Ein Wert wird der Reihe nach mit mehreren festen Möglichkeiten verglichen. Bei einem Treffer beginnt die Ausführung an dieser Stelle.

4:26 Und jetzt kommt der Satz, auf den es ankommt: Sie läuft ab dort weiter, bis ein break sie beendet. Nicht bis zum nächsten Fall — weiter, quer durch alle folgenden Fälle. Das ist kein Fehler im Sprachentwurf, sondern eine bewusste Möglichkeit, die man auch sinnvoll nutzen kann. Aber sie erklärt, warum ein vergessenes break so unangenehme Folgen hat.

4:46 Der default-Zweig fängt schließlich alles ab, was zu keiner Möglichkeit passt. Hier ist das Durchfallen absichtlich eingesetzt, und zwar sinnvoll. Die ersten beiden Marken stehen direkt untereinander, ohne Code dazwischen. Ergebnis: Beide Arten landen im selben Block, ohne dass Sie den Code doppelt schreiben müssen. Das ist die legitime Anwendung des Mechanismus, und Sie werden ihr in gutem Code begegnen.

5:10 Die Kehrseite sehen Sie am break unter jedem inhaltlichen Block — es steht dort nicht aus Höflichkeit, sondern weil sonst der nächste Fall gleich mitläuft. Und ganz unten der default-Zweig, der die Freifläche als Auffangbecken bereithält. Die Abgrenzung ist ähnlich klar wie beim ternären Operator. Die switch-Anweisung glänzt bei einem Wert gegen eine Liste exakter Treffer — Zustände, Kategorien, Befehlsnamen.

5:34 Sobald es um Bereiche geht, um zusammengesetzte oder komplexe Bedingungen, ist die if-Kette das ehrlichere Werkzeug. Die beiden unteren Punkte behandeln das Durchfallen von zwei Seiten, und diese Doppelnatur sollte man sich merken: Gewollt ist es ein nützliches Ausdrucksmittel, versehentlich ein Fehler, der in Ruhe reift.

5:53 Denn der Code läuft ja — er tut nur zu viel, und das merkt man oft erst spät. Bilden Sie eine Zuordnung ab, bei der zwei Arten sich einen Block teilen, ohne dass Sie den Code doppelt schreiben — und alles Übrige landet im default-Zweig. Damit setzen Sie das Durchfallen einmal bewusst ein. Der interessantere Teil ist der Hinweis: Entfernen Sie testweise ein break und beobachten Sie, wie weit die Ausführung läuft.

6:17 Diese kleine Sabotage lohnt sich, weil sie den Mechanismus körperlich erfahrbar macht. Danach vergessen Sie ein break vielleicht immer noch — aber Sie erkennen den Fehler in der Ausgabe sofort wieder. Das vergessene break ist der Klassiker und der Grund für die vorige Übung. Der zweite Punkt ist subtiler und in der Praxis mindestens so teuer: Wer den default-Zweig weglässt, ignoriert unbekannte Werte stillschweigend.

6:42 Es passiert dann einfach nichts — keine Ausgabe, keine Meldung, kein Hinweis. Solche Fehler zu finden, ist mühsam. Punkt drei ist eine Werkzeugfrage: Bereichsprüfungen gehören in ein if, nicht in eine Weiche. Und der letzte Punkt ist eine gute Nachricht mit Fallstrick — switch vergleicht strikt. Der Text mit der Ziffer trifft also nicht auf die Zahl.

7:03 Das ist richtig so, überrascht aber, wer es anders erwartet.

Schleifenarten im Überblick

7:07 Jetzt zur Wiederholung. Es gibt fünf Formen, und die gute Nachricht lautet: Sie brauchen nicht alle gleich gut zu beherrschen. Wichtig ist, die passende zu wählen — denn die richtige Wahl verhindert Fehler, bevor sie entstehen können. Eine Schleife wiederholt einen Codeblock, und die Formen unterscheiden sich vor allem darin, was das Ende bestimmt.

7:28 Bei der einen wissen Sie die Anzahl vorher — dreimal, zehnmal, so oft wie die Liste lang ist. Bei der anderen wissen Sie es nicht und prüfen stattdessen bei jedem Durchgang eine Bedingung. Und die dritte Gruppe arbeitet eine Sammlung ab und ist fertig, wenn die Sammlung durch ist. Diese drei Grundgedanken — feste Anzahl, offene Bedingung, vorhandene Sammlung — helfen bei der Auswahl mehr als jede Syntaxliste.

7:52 Die Logik hinter dieser Tabelle ist eine Frage: Was weiß ich vorher? Kenne ich die Anzahl oder brauche ich einen Zählindex, nehme ich die klassische Zählschleife. Ist offen, wie oft es laufen wird, prüfe ich eine Bedingung. Soll der Block auf jeden Fall mindestens einmal laufen — etwa eine Eingabeaufforderung —, gehört die Prüfung ans Ende.

8:12 Und wenn ich schlicht jedes Element einer Sammlung dranhaben will, dann sagt for-of genau das, ohne Zählerei. Den Merksatz unten sollten Sie wörtlich mitnehmen: for-of liefert Werte, for-in liefert Schlüssel. Diese beiden werden ständig verwechselt. Alle fünf Formen auf einem Blatt — vergleichen Sie vor allem die erste Zeile mit der vorletzten.

8:33 Oben führen Sie eine Zählvariable, prüfen sie gegen die Länge und erhöhen sie: drei Stellen, an denen etwas schiefgehen kann. Unten sagen Sie einfach, dass jeder Name drankommen soll. Kein Index, keine Grenze, keine Erhöhung — und damit auch keine Gelegenheit, sich um eins zu vertun. Deshalb ist for-of in den meisten Fällen die klarste Wahl, und deshalb ist es in modernem Code die häufigste.

8:56 Die klassische Zählschleife brauchen Sie noch, aber seltener, als Sie vielleicht denken. Lösen Sie dieselbe Ausgabe zweimal — einmal mit der klassischen Zählschleife und einmal mit for-of — und begründen Sie dann, welche Fassung Sie behalten würden. Die Begründung ist die eigentliche Aufgabe. Denn beide funktionieren; die Frage ist, welche weniger Gelegenheit zum Fehlermachen bietet.

9:19 Der Hinweis führt Sie zur Antwort: Brauchen Sie den Index nicht, brauchen Sie auch keine Zählvariable. Und was nicht existiert, kann nicht falsch sein. Das ist ein Prinzip, das weit über Schleifen hinaus trägt. Der erste Punkt ist der häufigste Anfängerfehler überhaupt: for-in auf ein Array. Es funktioniert scheinbar, liefert aber die Indizes als Text statt der Werte — und die Verwunderung ist groß.

9:43 Der zweite ist der berühmte Fehler um eins: kleiner-gleich statt kleiner, und schon greifen Sie einen Schritt zu weit. Punkt drei ist eine Entwurfsfrage: Die Form mit der Prüfung am Ende läuft garantiert mindestens einmal, und das ist manchmal genau falsch. Und der letzte fasst die Aufgabe zusammen — eine Zählvariable, die niemand braucht, ist nur eine zusätzliche Fehlerquelle.

Schleifen steuern

10:05 Jetzt greifen wir in die Schleife hinein. Zwei Schlüsselwörter erlauben es, den Ablauf zu unterbrechen — und eine Frage sollten Sie sich bei jeder bedingten Schleife stellen, weil sie vor der unangenehmsten Sorte Fehler schützt. Zwei Werkzeuge, die man auseinanderhalten muss. Das eine verlässt die Schleife sofort — Ende, es geht nach der Schleife weiter.

10:26 Das andere bricht nur den aktuellen Durchlauf ab und springt zum nächsten; die Schleife läuft weiter. Der Unterschied klingt klein und ist im Verhalten gewaltig. Der dritte Satz beschreibt das, was in jedem Entwicklerleben mindestens einmal passiert: die Endlosschleife. Sie entsteht, wenn die Abbruchbedingung nie falsch wird.

10:45 Das Programm hängt, die Lüfter drehen hoch, und man greift zur Tastenkombination zum Abbrechen. Passiert einmal — und danach stellt man die richtige Frage. Der obere Block zeigt beide Steuerbefehle nebeneinander und macht den Unterschied greifbar. Der leere Name wird übersprungen, die Schleife läuft weiter. Beim Namen West ist Schluss — was danach in der Liste steht, sieht das Programm nie.

11:09 Achten Sie darauf, dass beide vor der Ausgabe stehen; die Reihenfolge innerhalb des Blocks entscheidet mit, was passiert. Unten die Endlosfalle in Reinform. Die Erhöhung ist die einzige Zeile, die dafür sorgt, dass die Bedingung irgendwann nicht mehr gilt. Fehlt sie, läuft es ewig. Deshalb die Frage, die ich Ihnen mitgeben möchte: Was ändert sich, damit die Bedingung falsch wird?

11:32 Beim Suchen liegt der Nutzen auf der Hand: Haben Sie den ersten Treffer, ist jeder weitere Durchlauf verschwendete Zeit. Bei drei Einträgen fällt das nicht auf, bei einer Million schon. Der zweite Punkt ist eine Lesbarkeitsfrage und verwandt mit der Guard Clause aus dem letzten Modul: Wer Sonderfälle mit continue vorab abräumt, hält den Normalfall frei von zusätzlicher Verschachtelung.

11:53 Der dritte Punkt ist die Regel für bedingte Schleifen — es muss eine Größe geben, die sich nachweislich ändert. Und der letzte ist ein Warnsignal: Wer Marken braucht, um aus verschachtelten Schleifen zu springen, hat meist eine Struktur, die man besser aufteilt. Suchen Sie das erste passende Beet und brechen Sie ab, sobald Sie es haben.

12:12 Der Nachweis ist der schöne Teil: Zählen Sie die Durchläufe mit und vergleichen Sie mit der Fassung ohne Abbruch. Sie sehen dann in Zahlen, was Sie gespart haben — und das ist überzeugender als jede Behauptung über Effizienz. Bei einer kurzen Liste ist der Unterschied klein, aber das Prinzip skaliert. Genau dieser Blick, aus einer kleinen Messung auf das große Verhalten zu schließen, gehört zum Handwerk.

12:36 Die nicht veränderte Zählvariable ist die Endlosschleife, und sie hängt Ihnen den Prozess auf — unangenehm, aber lehrreich. Die Verwechslung der beiden Steuerbefehle produziert Programme, die entweder zu früh aufhören oder zu lange weiterlaufen. Der dritte Punkt ist eine Erwartung, die viele mitbringen: In verschachtelten Schleifen verlässt der Abbruch nur die innere.

12:57 Die äußere läuft munter weiter, und das Ergebnis wirkt zunächst unerklärlich. Und der letzte ist ein feiner: Wer nach dem Treffer weiterläuft, überschreibt ihn womöglich im nächsten Durchlauf. Dann ist der Fehler nicht das Fehlen eines Ergebnisses, sondern das falsche Ergebnis — und das ist schlimmer.

Eingaben prüfen

13:14 Zum Abschluss das Kapitel, in dem alles zusammenkommt. Hier entsteht zum ersten Mal ein kleines Programm, das mit einem Menschen redet. Und die Grundhaltung dabei ist: Was von außen kommt, ist zunächst unbestätigt. Drei Fragen stellt eine ordentliche Prüfung: Ist überhaupt ein Wert da? Hat er den richtigen Typ? Und liegt er im erwarteten Bereich?

13:36 Erst wenn alle drei mit Ja beantwortet sind, darf damit gearbeitet werden. Der zweite Satz ist der praktisch wichtigste: Über die Kommandozeile kommt jede Eingabe zunächst als Zeichenkette an — ausnahmslos. Die Zahl, die der Nutzer eintippt, ist keine Zahl, sondern Text, der wie eine Zahl aussieht. Und das gilt genauso für Formulare im Browser und für vieles, was aus Schnittstellen kommt. Hier treffen sich alle Themen der letzten Module.

14:03 Der rote Faden dieser fünf Schritte ist eine Trichterform: von grob nach fein. Zuerst die einfachste Frage — ist überhaupt etwas da? Eine leere Eingabe ist unwahr und damit bequem erkennbar. Dann die Umwandlung in eine Zahl, und wichtig: unmittelbar danach die Prüfung, ob das gelungen ist. Der dritte Schritt ist der, den man am liebsten vergisst — der Wertebereich.

14:25 Dass etwas eine Zahl ist, heißt nicht, dass sie sinnvoll ist; ein Beet mit minus vier Jahren ist eine gültige Zahl und trotzdem Unsinn. Ja-Nein-Eingaben prüft man gegen eine feste Liste erlaubter Wörter. Und jeder Fehlschlag bekommt eine eigene, konkrete Meldung. Drei Prüfungen, drei verschiedene Muster — und alle drei werden Sie wiederverwenden. Oben das Pflichtfeld: erst die Leerzeichen am Rand entfernen, dann prüfen.

14:51 Ohne dieses Abschneiden wäre eine Eingabe aus drei Leerzeichen gültig. In der Mitte die Zahl mit einer dreiteiligen Bedingung — misslungene Umwandlung, zu klein, zu groß. Unten der wichtigste Teil, und der Fußtext sagt es unmissverständlich: Übergeben Sie eine Ja-Nein-Antwort niemals direkt an die Umwandlungsfunktion. Das Wort „nein" ist eine nicht-leere Zeichenkette und damit wahr. Stattdessen prüfen wir gegen eine Liste erlaubter Wörter und leiten den Wahrheitswert erst danach ab.

15:21 Bauen Sie ein kleines Programm, das ein Beet über die Kommandozeile anlegt — mit drei Fehlerfällen, die je eine eigene, verständliche Meldung bekommen: leere Eingabe, eine Jahreszahl, die keine ist, und ein anderes Wort als ja oder nein. Achten Sie auf das Wort „verständlich". Eine Meldung, die nur sagt, dass etwas falsch war, hilft niemandem; sie muss sagen, was erwartet wurde.

15:44 Zwei Sprachmittel im Beispiel — der Import und das Warten auf eine Antwort — erklären wir in späteren Modulen. Hier zählt allein die Prüflogik. Der erste Punkt ist die Kernbotschaft des Kapitels und deshalb hier noch einmal: Eine Ja-Nein-Antwort direkt in einen Wahrheitswert umzuwandeln, macht jede nicht-leere Antwort zu einem Ja.

16:03 Der zweite ist der vergessene Wertebereich — Typprüfung allein lässt Unsinn durch. Die fehlenden Leerzeichen am Rand sind ein unterschätzter Ärger: Der Nutzer hat alles richtig eingegeben, das Programm lehnt trotzdem ab, weil ein Leerzeichen mitgekommen ist. Und der letzte Punkt betrifft die Qualität Ihrer Software mehr, als Entwickler meist annehmen — eine Fehlermeldung, die nicht sagt, was erwartet wurde, ist kaum besser als gar keine.

Der Ablauf ist jetzt steuerbar

16:28 Drei Merksätze aus diesem Modul. Der ternäre Operator wählt einen Wert, if steuert die Ausführung — das ist die Trennlinie zwischen beiden. Die switch-Anweisung braucht ihr break, sonst läuft die Ausführung in den nächsten Fall hinein. Und bei den Schleifen: for-of liefert Werte, for-in liefert Schlüssel. Dazu kommt die Haltung aus dem letzten Kapitel, die Sie ab jetzt behalten sollten — was von außen hereinkommt, wird geprüft, bevor damit gearbeitet wird.

16:55 Im nächsten Modul geht es um die Datenstrukturen selbst: Arrays, Objekte, Maps und Sets.