Ausdrücke, Operatoren und Bedingungen

JavaScript — Operatoren und Bedingungen

0:00 Alles, was wir bisher geschrieben haben, lief geradeaus: von oben nach unten, jedes Mal gleich. Damit ist jetzt Schluss. In diesem Modul lernt Ihr Programm, auf Daten zu reagieren — und das ist der Moment, in dem aus einer Abfolge von Anweisungen tatsächlich Software wird. Der rote Faden ist dabei überraschend schlicht: Jeder Schritt, den wir uns ansehen, läuft am Ende auf einen Wahrheitswert hinaus.

0:24 Rechnen, Vergleichen, Verknüpfen — all das dient dazu, eine Frage mit Ja oder Nein zu beantworten. Und aus dieser Antwort entsteht die Entscheidung.

Entscheidungen im Code

0:34 Der zweite Tag beginnt mit sechs Kapiteln, die eine klare Steigerung haben. Zuerst klären wir drei Begriffe, die im Alltag oft synonym verwendet werden und trotzdem Verschiedenes bedeuten. Dann die Rechenoperatoren — mit einem Operator, der eine Sonderrolle spielt und regelmäßig für Verwirrung sorgt. Danach Zuweisungen in ihrer kurzen Form, die Frage nach Gleichheit, die logischen Verknüpfungen und schließlich die Verzweigung selbst.

0:59 Am Ende dieses Moduls trifft Ihr Code eigene Entscheidungen — und Sie wissen, worauf er sie stützt.

Ausdrücke, Operatoren, Bedingungen

1:05 Beginnen wir mit dem Vokabular. Drei Begriffe, die den Rest des Moduls tragen — und die man auseinanderhalten sollte, bevor es in die Details geht. Wir halten das bewusst kurz; die Tiefe kommt in den folgenden Kapiteln. Drei Begriffe, drei klare Rollen. Ein Ausdruck ist alles, was einen Wert erzeugt — eine Rechnung, ein Vergleich, ein Variablenname.

1:27 Ein Operator ist das Zeichen, das eine Operation ausführt, und die Werte, auf die er wirkt, heißen Operanden. Ein Plus zwischen zwei Zahlen: Operator in der Mitte, Operanden links und rechts, das Ganze ist ein Ausdruck. Eine Bedingung schließlich führt Code nur dann aus, wenn ein Ausdruck wahr ergibt. Das ist die Verbindung, um die es geht — der Ausdruck liefert die Antwort, die Bedingung zieht daraus die Konsequenz.

1:53 Hier stehen alle drei nebeneinander. Die beiden Zeilen in der Mitte sind Ausdrücke — sie ergeben etwas. Die erste eine Zahl, die zweite einen Wahrheitswert. Beachten Sie: Sie tun nichts damit, das Ergebnis verpufft. Erst unten wird es interessant: Dort steht derselbe Gedanke in einer Bedingung, und jetzt hat der Wahrheitswert eine Konsequenz.

2:14 Damit beginnt der Kontrollfluss — der Weg, den JavaScript durch Ihren Code nimmt. Bisher lief dieser Weg immer stur von oben nach unten. Ab dieser Zeile kann er sich verzweigen, und das ist der eigentliche Fortschritt dieses Moduls. Warum das nötig ist, merkt man beim ersten Kontakt mit echten Daten. Ein Programm ohne Bedingungen macht immer dasselbe — es ist eine Rolltreppe, keine Software.

2:39 Echte Daten aber sind unregelmäßig: Ein Beet ist aktiv oder nicht, ein Feld fehlt, ein Wert ist zu groß. Auf jeden dieser Fälle muss reagiert werden. Und der schöne Teil ist: Jede dieser fachlichen Fragen lässt sich als Ausdruck formulieren, der wahr oder falsch ergibt. Aus dieser Übersetzung — Fachfrage in Wahrheitswert — entsteht die Verzweigung. Und aus Verzweigungen entsteht ein Programm, das jemandem nützt.

3:05 Diese Übung trainiert eine Fähigkeit, die man leicht unterschätzt: Fachliches in Code zu übersetzen. Formulieren Sie drei Fragen an ein Beet-Objekt und schreiben Sie sie als Ausdrücke hin — Ist das Beet aktiv? Wird es länger als fünf Jahre bestellt? Ist es ein Kräuterbeet? Jede dieser Fragen muss nachweislich wahr oder falsch ausgeben. Es klingt einfach, und der Code ist es auch.

3:28 Der Lerneffekt liegt woanders: Sie merken, wie präzise eine Frage sein muss, damit sie überhaupt in einen Ausdruck passt. Unscharfe Fragen lassen sich nicht programmieren. Ausdruck und Anweisung zu verwechseln, ist der begriffliche Klassiker — nur der Ausdruck liefert einen Wert, den man weiterverwenden kann. Der zweite Punkt ist praktisch relevanter: Bedingungen, die niemals falsch werden können. Das passiert schneller, als man denkt, und der zugehörige Zweig wird dann nie erreicht.

3:58 Punkt drei knüpft an das vorige Modul an: Einen Wert zu prüfen, ohne seinen Typ zu kennen, führt zu Ergebnissen, die man nicht vorhersagen kann. Und der letzte Punkt ist eine Reihenfolgefrage — erst die Frage klären, dann die Verzweigung bauen. Umgekehrt entsteht Code, der Fälle behandelt, die es gar nicht gibt.

Rechenoperatoren

4:16 Jetzt zu den Grundrechenarten. Klingt nach dem einfachsten Kapitel des Moduls — und wäre es auch, wenn da nicht ein Operator wäre, der je nach Typ etwas völlig anderes tut. Er sorgt für einen der häufigsten Anfängerfehler überhaupt. Rechenoperatoren verknüpfen Zahlen — das ist zunächst unspektakulär und funktioniert, wie man es aus der Schule kennt. Die Ausnahme ist das Plus, und sie hat es in sich.

4:41 Bei Zahlen addiert es. Bei Zeichenketten verbindet es sie zu einem längeren Text. Das ist praktisch, solange klar ist, womit man arbeitet. Sobald aber Zahl und Text aufeinandertreffen, entscheidet die Sprache selbst, und sie entscheidet sich für das Verketten. Aus zwei plus drei wird dann nicht fünf, sondern die Zeichenfolge zwei-drei. Behalten Sie das im Kopf, wenn gleich Werte aus Eingabefeldern ins Spiel kommen.

5:07 Die ersten beiden Zeilen zeigen die Sonderrolle des Plus in ihrer ganzen Schlichtheit: gleiche Zeichen, völlig anderes Ergebnis, nur weil Anführungszeichen dabeistehen. In der Mitte der Restwert-Operator, den viele aus der Schule als „Modulo" kennen. Er liefert, was bei einer Division übrig bleibt, und ist damit das Standardwerkzeug für Teilbarkeitsfragen — die Zeile darunter zeigt es.

5:29 Achten Sie außerdem auf die Division: JavaScript kennt keine Ganzzahldivision, es kommt eine Kommazahl heraus. Und unten die Vorrangregeln, die auch hier gelten. Mein Rat: Setzen Sie im Zweifel Klammern. Sie kosten nichts und machen die Absicht eindeutig. Was diese vier Zeilen unterscheidet, ist nicht das Ergebnis in der Variablen — das ist immer gleich.

5:51 Unterschiedlich ist, was der Ausdruck selbst zurückgibt: den alten Wert oder den neuen. Steht das Zeichen hinter der Variablen, bekommen Sie noch den alten Wert und die Erhöhung passiert danach. Steht es davor, wird zuerst erhöht. In Schleifen und Zählern begegnet Ihnen das ständig, und dort spielt der Unterschied meist keine Rolle.

6:10 Genau deshalb der Rat im Fußtext, den ich unterstreichen möchte: Bauen Sie nie ein Programm auf diesen Unterschied. Wer die Erhöhung mitten in einen größeren Ausdruck packt, schreibt ein Rätsel statt Code. Eine kleine Übung mit großem Wiedererkennungswert: Prüfen Sie, ob eine Zahl gerade ist. Die Logik dahinter ist der Restwert bei Division durch zwei — er ist genau dann null, wenn die Zahl gerade ist. Belegen Sie es mit je zwei Beispielen für beide Fälle.

6:38 Warum lohnt sich diese kleine Aufgabe? Weil das Muster überall wiederkehrt: jede zweite Tabellenzeile einfärben, jede zehnte Verarbeitung protokollieren, Werte auf Gruppen verteilen. Der Restwert-Operator ist eines dieser unscheinbaren Werkzeuge, die man dauernd braucht, sobald man sie einmal kennt. Der erste Punkt ist der versprochene Klassiker: Zwei Zahlen aus Textfeldern mit Plus zu verbinden, ergibt keine Summe, sondern eine längere Zeichenkette.

7:05 Und weil das keinen Fehler auslöst, merkt man es erst am unsinnigen Ergebnis. Der zweite Punkt ist eine Haltungsfrage — Vorrangregeln raten statt klammern. Sie haben vielleicht recht, aber der nächste Leser muss es nachschlagen. Postfix und Präfix zu verwechseln, kostet Sie einen Wert, der um eins danebenliegt. Und die letzte Erwartung stammt aus anderen Sprachen: Eine Division ergibt hier eine Kommazahl, keine gekürzte Ganzzahl.

Zuweisungsoperatoren

7:32 Weiter mit den Kurzformen beim Zuweisen. Die sind schnell erklärt und sparen Schreibarbeit. Interessant wird es am Ende des Kapitels, wo ein Thema aus dem vorigen Modul in neuer Gestalt zurückkehrt. Ein Zuweisungsoperator schreibt einen Wert in eine Variable — das kennen wir seit dem zweiten Modul. Neu sind die kombinierten Formen.

7:52 Sie verbinden die Zuweisung mit einer Rechnung oder einer logischen Prüfung und aktualisieren den Wert auf Basis dessen, was schon drinsteht. Statt zu sagen „nimm den bisherigen Wert, addiere fünf, schreib das Ergebnis zurück", sagen Sie kurz: „erhöhe um fünf". Das ist nicht nur kürzer, es ist auch näher an dem, was Sie gedanklich tun. Und weil der Variablenname nur einmal vorkommt, gibt es eine Fehlerquelle weniger.

8:18 Sechs Zeilen, immer dasselbe Prinzip: bisherigen Wert nehmen, verrechnen, zurückschreiben. Alle Grundrechenarten haben so eine Kurzform, auch Restwert und Potenz. Lesen Sie die Zeilen einmal von oben nach unten mit — die Kommentare zeigen den Zwischenstand, und Sie sehen, wie sich ein einziger Wert schrittweise verändert.

8:37 Der Block ganz unten ist der eigentlich interessante: Dieselbe Kurzform funktioniert auch mit Text, und dann verkettet sie. Das ist konsequent, weil das Plus sich bei Zeichenketten immer so verhält — es überrascht trotzdem regelmäßig, wenn eine Variable unbemerkt zum Text geworden ist. Hier kehrt das Thema aus dem vorigen Modul zurück, diesmal als Zuweisung.

8:58 Die erste Variante greift bei jedem unwahren Wert — und die leere Zeichenkette oben ist genau so ein Fall, sie wird ersetzt. Die zweite greift nur bei null und undefined, deshalb bleibt der Zählerstand null erhalten. Dieselbe Entscheidung wie beim Fallback, nur in kompakterer Schreibweise. Und die dritte Variante ganz unten ist die seltenste: Sie weist nur zu, wenn bereits ein wahrer Wert dasteht.

9:21 Man begegnet ihr gelegentlich; wo eine schlichte Bedingung klarer wäre, sollte man ihr aber nicht nachgeben. Die Aufgabe ist bewusst dieselbe Situation wie im vorigen Modul, jetzt in Zuweisungsform — Wiederholung ist hier Absicht, weil dieser Fehler so verbreitet ist. Ein Zähler mit dem gültigen Wert null behält seinen Wert, ein fehlendes Feld bekommt den Ersatzwert.

9:42 Testen Sie dieselbe Zeile einmal mit der einen und einmal mit der anderen Variante und sehen Sie sich beide Ergebnisse an. Wenn Sie den Unterschied zweimal selbst produziert haben, treffen Sie diese Entscheidung künftig automatisch richtig — und das ist genau das Ziel. Der erste Punkt ist der bekannte, und er verdient die Wiederholung: Die Oder-Zuweisung überschreibt die gültige Null und die gültige leere Zeichenkette.

10:07 Der zweite ist ein Maßhalte-Hinweis. Kurzformen sind gut, gehäufte Kurzformen ergeben eine Zeile, die niemand mehr auseinandernimmt — Kürze ist kein Selbstzweck. Die Und-Zuweisung ist ein legitimes Werkzeug, aber selten das klarste; wo eine normale Bedingung verständlicher ist, nehmen Sie die. Und der letzte Punkt schließt an das Rechenkapitel an: Die Plus-Zuweisung verkettet bei Zeichenketten.

10:29 Wenn eine Zahl versehentlich als Text vorliegt, wächst sie nicht, sie wird länger.

Vergleich und Gleichheit

10:35 Jetzt eine der bekanntesten Eigenheiten von JavaScript: Es gibt zwei Arten, auf Gleichheit zu prüfen. Die Empfehlung nehme ich vorweg — nehmen Sie immer die strikte. Warum, das schauen wir uns jetzt an, und am Ende knüpfen wir an die Referenzen aus Modul drei an. Vergleichsoperatoren stellen zwei Werte gegenüber und liefern einen Wahrheitswert — größer, kleiner, gleich. Bei der Gleichheit wird es besonders: JavaScript kennt zwei Formen.

11:01 Die lose Gleichheit wandelt die Typen vorher an, damit ein Vergleich möglich wird. Die strikte tut das nicht — sie prüft Wert und Typ gemeinsam und meldet Ungleichheit, wenn die Typen nicht passen. Historisch gab es gute Gründe für die lose Variante; heute ist sie fast immer die falsche Wahl, weil sie Umwandlungen vornimmt, die niemand angefordert hat.

11:22 Die Regeln dafür sind ausgefeilt und nicht intuitiv. Die ersten beiden Zeilen sagen alles: Derselbe Vergleich, ein Zeichen Unterschied, entgegengesetztes Ergebnis. Die lose Form wandelt den Text in eine Zahl und findet Gleichheit. Die strikte sagt schlicht: Ein Text ist keine Zahl. Der spannendere Teil steht unten, und er knüpft direkt an die Referenz-Semantik aus dem vorigen Modul an.

11:45 Zwei Objekte mit identischem Inhalt sind trotzdem nicht gleich — weil verglichen wird, ob es sich um dasselbe Objekt handelt, nicht ob es gleich aussieht. Zwei Zettel mit derselben Anschrift darauf zeigen auf dasselbe Haus; zwei Häuser mit gleicher Hausnummer sind nicht dasselbe Haus. Die Begründung ist erfreulich pragmatisch: Die strikte Form prüft Wert und Typ, und das ist fast immer die Frage, die Sie eigentlich stellen.

12:10 Die lose Form beantwortet eine andere Frage — nämlich ob die Werte nach einer Umwandlung übereinstimmen —, und die stellt fast niemand bewusst. Dazu kommt die Lesbarkeit: Wenn nichts im Verborgenen umgewandelt wird, steht im Code genau das, was passiert. Erwähnenswert ist noch eine dritte Prüffunktion, die Sonderfälle sauber behandelt — den Wert NaN etwa, der sich selbst gegenüber als ungleich verhält.

12:33 Sie brauchen sie selten, aber es ist gut zu wissen, dass es sie gibt. Führen Sie den Unterschied selbst vor: Zwei inhaltsgleiche Objekte ergeben ungleich, zwei Variablen, die auf dasselbe Objekt zeigen, ergeben gleich. Und dann der wichtigste Teil der Aufgabe — erklären Sie beides. Wer das in eigenen Worten sagen kann, hat die Referenz-Semantik wirklich verstanden und nicht nur gesehen.

12:56 Vergleichen Sie zusätzlich zwei gleiche Zeichenketten; dort ist das Ergebnis nämlich anders, weil primitive Werte über ihren Inhalt verglichen werden. Der Kontrast zwischen diesen beiden Fällen ist die eigentliche Lektion. Die lose Gleichheit zu verwenden, ist der Ausgangspunkt für Vergleiche, die auf unerklärliche Weise zutreffen.

13:16 Der zweite Punkt trifft besonders diejenigen, die aus Sprachen mit Wertsemantik kommen: Objekte mit dem Gleichheitsoperator zu vergleichen und Inhaltsgleichheit zu erwarten, führt zuverlässig ins Leere. Wer wirklich Inhalte vergleichen will, muss das selbst formulieren. Der NaN-Vergleich ist ein Kuriosum mit praktischen Folgen — dieser Wert ist sich selbst nicht gleich, dafür gibt es die erwähnte Sonderfunktion.

13:38 Und der letzte Punkt ist die Verbindung zum Typkapitel: Zahlen aus Text vergleicht man erst nach der Umwandlung, nicht davor.

Boolesche Logik, truthy und falsy

13:46 Jetzt verknüpfen wir Bedingungen miteinander. Und wir sehen uns an, was JavaScript eigentlich alles als wahr durchgehen lässt — denn das ist deutlich mehr, als man erwarten würde, und die Ursache für eine Klasse von Fehlern, die spät auffallen. Drei logische Operatoren, und ihre Bedeutung entspricht der Umgangssprache. Das doppelte Kaufmanns-Und verlangt, dass beide Seiten wahr sind.

14:08 Der doppelte Strich verlangt mindestens eine. Das Ausrufezeichen kehrt um. Bis hierhin ist alles wie erwartet. Der Zusatz am Ende ist die Besonderheit: JavaScript wertet in Bedingungen auch Werte aus, die gar keine Wahrheitswerte sind. Es entscheidet dann selbst, ob so ein Wert als wahr oder falsch durchgeht — die Begriffe dafür sind truthy und falsy.

14:29 Diese Bequemlichkeit ist alltagstauglich und, wie wir gleich sehen, an einer Stelle gefährlich. Oben die Verknüpfungen im Alltagsgebrauch: zwei Bedingungen mit Und, zwei mit Oder, dazu eine Umkehrung. Beachten Sie den Hinweis in der Beschriftung — das Und bindet stärker als das Oder, ähnlich wie Punkt vor Strich. Wo beide gemischt vorkommen, gehören Klammern hin.

14:52 Der untere Block ist der lehrreiche. Vier Werte, die alle kein Wahrheitswert sind, durch die Umwandlungsfunktion geschickt. Der Text mit dem Wort „false" gilt als wahr, weil er nicht leer ist. Und leeres Array und leeres Objekt gelten ebenfalls als wahr, weil sie gültige Objekte sind — Leere im umgangssprachlichen Sinn spielt hier keine Rolle.

15:14 Hier kommt der praktisch wichtigste Hinweis des Kapitels. Alles, was von außen in Ihr Programm kommt — von der Kommandozeile, aus einem Formular, aus einer Schnittstelle —, kommt zunächst als Text an. Und Text ist wahr, solange er nicht leer ist. Das heißt: Die Zeichenfolge mit dem Wort „false" darin schaltet Ihre Funktion ein statt aus.

15:34 Der Nutzer hat alles richtig gemacht, das Programm macht das Gegenteil. Umgekehrt gilt für die Null: Sie ist unwahr, aber fachlich oft völlig gültig — null Grad, null Artikel, null Prozent. Deshalb die Regel: Sobald die Null gültig ist, gehört der nullish-Operator hin. Bauen Sie den Fall nach, der in echten Anwendungen für ratlose Gesichter sorgt: Die Eingabe mit dem Wort „false" darf nicht als falsch behandelt werden, weil sie es für JavaScript nicht ist.

16:02 Wandeln Sie sie stattdessen bewusst um, bevor Sie prüfen. Und als Vorbereitung: Schicken Sie die Zeichenkette einmal durch die Umwandlungsfunktion und sehen Sie sich an, was JavaScript davon hält. Dieser Blick ist der eigentliche Wert der Aufgabe — danach vertrauen Sie keinem Textwert mehr blind in einer Bedingung. Textwerte direkt als Bedingung zu prüfen, ist der Fehler, den die vorige Aufgabe adressiert — und er begegnet Ihnen im Berufsalltag garantiert bei Umgebungsvariablen.

16:30 Das leere Array als unwahr anzunehmen, ist ein Import aus anderen Sprachen; hier ist es ein Objekt und damit wahr. Wer wissen will, ob es leer ist, fragt nach seiner Länge. Bei gemischten Und- und Oder-Verknüpfungen die Bindung zu raten, ist dasselbe Problem wie bei Punkt vor Strich — klammern Sie. Und der letzte Punkt ist unser Dauergast: Die Null mit dem Oder-Operator zu ersetzen, obwohl sie der richtige Wert wäre.

Bedingungen mit if und else

16:54 Zum Abschluss die Verzweigung selbst. Die Mechanik ist in fünf Minuten erklärt. Die Technik, die aus diesem Kapitel am längsten hängen bleibt, steht am Ende — sie verändert, wie Ihr Code aussieht, mehr als jede andere Kleinigkeit dieses Moduls. Die Mechanik ist geradlinig: Ist der Ausdruck wahr, läuft der Block. Ist er es nicht, kommt der else-Zweig zum Zug.

17:16 Und mit else if lassen sich beliebig viele Prüfungen aneinanderreihen. Der entscheidende Satz steht am Ende: Die erste zutreffende Bedingung gewinnt, alles Weitere wird übersprungen. Daraus folgt etwas, das man leicht übersieht — die Reihenfolge Ihrer Zweige ist Teil der Logik, nicht bloß Formatierung. Wer die allgemeinste Bedingung nach oben stellt, sorgt dafür, dass die spezielleren darunter nie erreicht werden.

17:41 Der Code läuft dann fehlerfrei und tut trotzdem nie, was gemeint war. Ein klassischer Stufenvergleich, und die Kommentare verraten das Ergebnis: Sieben Jahre landet im mittleren Zweig. Interessant ist, warum. Die erste Bedingung prüft auf weniger als fünf und trifft nicht zu. Die zweite prüft auf weniger als zehn — und ab hier ist implizit klar, dass der Wert mindestens fünf beträgt, weil der erste Zweig ihn sonst gefangen hätte.

18:06 Genau dieses stillschweigende Mitdenken macht Ketten so kompakt und zugleich so anfällig für Umsortierung. Wenn Sie die Reihenfolge dieser Zweige tauschen, ändert sich das Verhalten grundlegend, ohne dass eine einzige Bedingung verändert wurde. Das ist die versprochene Technik, und der Vergleich spricht für sich. Oben zwei ineinander verschachtelte Bedingungen — schon bei zwei Ebenen muss man beim Lesen mitverfolgen, in welchem Kontext man sich gerade befindet.

18:33 Unten dasselbe Verhalten, aber flach: Der Sonderfall wird zuerst geprüft, und wenn er zutrifft, ist die Sache erledigt. Was danach kommt, beschreibt nur noch den Normalfall. Der Gewinn ist nicht die eingesparte Zeile, sondern die entfallene Gedankenlast. Und der Effekt wächst mit der Größe: Bei drei oder vier Prüfungen ist der Unterschied zwischen beiden Fassungen der zwischen lesbar und unlesbar.

18:56 Nehmen Sie eine verschachtelte Bedingung und legen Sie sie flach — mit höchstens einer Verschachtelungsebene. Die entscheidende Auflage: Für alle Eingaben müssen dieselben Ergebnisse herauskommen wie vorher. Das ist der Unterschied zwischen Umbauen und Kaputtmachen, und genau diese Disziplin brauchen Sie später beim Refactoring.

19:14 Ein Hinweis, falls eine Bedingung dabei lang wird: Sie darf über mehrere Zeilen laufen. Das bleibt eine Bedingung, und sie ist umgebrochen oft deutlich besser lesbar als in einer einzigen sehr langen Zeile. Der erste Punkt ist der berüchtigtste: ein einzelnes Gleichheitszeichen in der Bedingung. Das vergleicht nicht, das weist zu — und weil die Zuweisung einen Wert liefert, läuft der Code sogar, nur eben immer im selben Zweig.

19:39 Der zweite Punkt ist die Reihenfolgefalle, die wir bei der Kette gesehen haben: ein Zweig, der nie erreicht wird. Immer tiefer zu verschachteln, statt früh auszusteigen, ist die Gewohnheit, die die Guard Clause ersetzt. Und die weggelassenen geschweiften Klammern sind eine Zeitbombe — sie funktionieren genau so lange, bis jemand eine zweite Zeile einfügt.

Das Programm entscheidet jetzt selbst

20:00 Drei Sätze zum Mitnehmen. Erstens: Jede Bedingung ist am Ende ein Ausdruck, der auf einen Wahrheitswert hinausläuft — das war der rote Faden dieses Moduls. Zweitens: Die strikte Gleichheit ist die Standardwahl, die lose wandelt vorher um und überrascht. Und drittens die Stolperfallen, die Sie ab jetzt kennen: die Null, die leere Zeichenkette und der Text mit dem Wort „false" darin. Ihr Programm trifft jetzt Entscheidungen.

20:26 Im nächsten Modul lernt es, Dinge zu wiederholen — es geht um Verzweigungen, Schleifen und die Prüfung von Eingaben.