Typinferenz und sichere Grundtypen

Typinferenz und sichere Grundtypen

0:00 Im ersten Modul haben wir geklärt, was Typen sind und was aus ihnen wird. Jetzt geht es darum, sie gut zu schreiben — und die überraschende Antwort lautet oft: möglichst wenig schreiben. Der Compiler weiß das meiste von allein. Durch dieses ganze Modul zieht sich eine einzige Frage, und ich empfehle Ihnen, sie sich bei jedem Typ zu stellen: Welche unmöglichen Zustände schließt dieser Typ aus?

0:23 Nicht, welche Werte er erlaubt — welche er verbietet. Alles Weitere, von den Bausteinen über Signaturen bis zu geprüften Konfigurationen, folgt aus dieser einen Frage.

Typinferenz und sichere Grundtypen

0:34 Die Leitlinie dieses Kapitels ist ökonomisch gemeint: Präzision am Typ spart Prüfungen an jeder einzelnen Verwendungsstelle. Was Sie einmal an der Modellierung investieren, holen Sie an zwanzig Stellen wieder herein, an denen Sie eben nicht mehr nachfragen müssen, ob ein Feld gefüllt ist. Wir arbeiten uns von der Inferenz über die Bausteine und Signaturen zu den Werkzeugen vor, mit denen aus Werten Typen werden — und schließen mit einer Übung, in der Sie das an echten Auftragsdaten durchspielen.

Typinferenz und explizite Annotationen

1:01 Beginnen wir mit einer Gewohnheit, die viele aus anderen Sprachen mitbringen: alles hinschreiben. In TypeScript ist das nicht nur unnötig, es schadet sogar. Ableiten ist hier der Normalfall — und Annotieren eine Entscheidung, die man begründen können sollte. TypeScript leitet die meisten Typen selbst ab, und zwar erstaunlich genau. Deshalb ist eine explizite Annotation kein Sicherheitsgewinn — der Compiler wusste es ohnehin schon.

1:27 Sie ist etwas anderes, nämlich Dokumentation einer Absicht. Ein Bild dazu: Ein Schild „Ausgang" über der Tür macht die Tür nicht sicherer. Es sagt nur allen, dass sie als Ausgang gedacht ist. Genauso sind Annotationen sinnvoll dort, wo eine spätere Änderung auffallen soll — und überflüssig dort, wo der abgeleitete Typ ohnehin genauer ist als der, den Sie geschrieben hätten.

1:49 Und das ist häufiger der Fall, als man denkt. Vier Faustregeln, und alle folgen demselben Gedanken: Annotieren Sie an Grenzen, nicht im Inneren. An exportierten Signaturen — sie sind eine Zusage nach außen, und Zusagen schreibt man auf. Am Rückgabewert öffentlicher Funktionen, damit ein Umbau dort sichtbar wird, statt sich lautlos durch das Projekt zu ziehen.

2:12 Und dort, wo der abgeleitete Typ zu weit ist, etwa eine allgemeine Zeichenkette statt einer festen Auswahl. Nicht dagegen an lokalen Variablen mit offensichtlichem Startwert. Wer dort annotiert, schreibt nur ab, was ohnehin danebensteht. Hier eine kleine Neuerung mit erstaunlich großer Alltagswirkung. Bis Version 5.9 galt: Eine Funktion in Methodenschreibweise konnte ihre Parameter nicht aus dem Kontext ableiten — Sie bekamen eine Fehlermeldung und mussten annotieren.

2:41 Deshalb kursiert bis heute der Rat, in Objekten lieber Pfeilfunktionen zu verwenden. Seit 6.0 ist dieser Grund entfallen: Verwendet eine Funktion das eigene Objekt im Rumpf gar nicht, leitet der Compiler sauber ab. Sie können also wieder schreiben, was sich natürlicher liest. Ein gutes Beispiel dafür, dass Ratschläge im Netz ein Verfallsdatum haben — dieser hier ist abgelaufen.

3:04 Die häufigste Überkorrektur beim Einstieg steht ganz oben: alles annotieren. Das macht den Code nicht sicherer, nur schwerer änderbar — jede Änderung wird zur doppelten Arbeit, einmal am Code und einmal an der Beschreibung. Das Gegenteil ist ebenfalls ein Fehler: Rückgabetypen an öffentlichen Funktionen wegzulassen, sodass Umbauten still durchrutschen.

3:25 Und der dritte Punkt ist der gerade genannte: Ratschlägen zu folgen, deren Grund es nicht mehr gibt. Prüfen Sie bei jeder Regel, die Sie übernehmen, ob sie noch gilt.

Primitive, Arrays, Tupel und Objekte

3:35 Jetzt zu den Bausteinen. Sie wirken banal — eine Liste ist eine Liste —, aber jeder von ihnen trägt eine fachliche Aussage, die man ihm nicht ansieht. Und wenn diese Aussage nicht stimmt, merkt man es oft erst Monate später an einer ganz anderen Stelle. Achten Sie auf das Muster in dieser Tabelle: Jeder Baustein trifft eine Aussage über Anzahl und Bedeutung — und wird falsch, wenn die Wirklichkeit anders aussieht.

4:01 Ein Array sagt: beliebig viele, alle gleichartig. Falsch, sobald die Anzahl fachlich feststeht. Ein Tupel sagt: feste Anzahl, feste Bedeutung je Position. Falsch, sobald die Liste wachsen darf. Ein Objekttyp sagt: Ich kenne die Schlüssel. Eine Index-Signatur sagt genau das Gegenteil. Die häufigste Verwechslung ist die letzte Zeile — eine Index-Signatur zu wählen, obwohl die Schlüssel bekannt sind.

4:26 Damit verschenken Sie jede Prüfung, die der Compiler für Sie hätte machen können. Ein Zeitraum besteht aus Beginn und Ende — zwei Werte, feste Bedeutung, nie drei. Trotzdem sieht man dafür fast immer eine Liste von Zeichenketten, mit einem Kommentar daneben, welcher der beiden der Beginn ist. Das Tupel sagt dasselbe, aber verbindlich: genau zwei Werte, und die Positionen haben Namen.

4:50 Diese Namen kosten Sie nichts, keine Laufzeit und keine Zeile — sie ersparen aber die Rückfrage, in welcher Reihenfolge die beiden stehen. Und das ist genau die Art von Rückfrage, die sonst in jedem Code-Review wieder auftaucht. Fachliche Aussagen gehören in den Typ, nicht in den Kommentar. Alle drei Punkte sind Varianten desselben Fehlers: Der Typ sagt weniger, als man weiß.

5:13 Ein Wertepaar als Liste modellieren und die Reihenfolge im Kommentar erklären — der Kommentar wird nicht geprüft. Index-Signaturen einsetzen, obwohl die Schlüssel bekannt sind — dann tippt sich jeder Zugriff ins Blaue. Und Objekttypen mit immer mehr optionalen Feldern überfrachten, statt echte Varianten zu bilden. Der letzte Punkt führt uns direkt zum nächsten Modul: Was dort als „vielleicht da, vielleicht nicht" modelliert wird, ist in Wahrheit meist eine Union verschiedener Zustände.

Funktionen, Rückgaben und Overloads

5:42 Signaturen sind die Stellen, an denen Ihr Code mit anderem Code spricht. Und Overloads sind das mächtigste Werkzeug dafür — sowie das am häufigsten überstrapazierte. Sehen wir uns an, wann sie wirklich angebracht sind und wann etwas anderes die ehrlichere Antwort ist. Ein Overload beschreibt mehrere zulässige Aufrufformen derselben Funktion.

6:02 Stellen Sie sich einen Schalter im Amt vor, an dem Sie sowohl einen Pass beantragen als auch einen Wohnsitz ummelden können — zwei wirklich verschiedene Vorgänge am selben Schalter. Dafür sind Overloads gedacht. Selten angebracht sind sie, wenn sich nur ein Parameter ändert, der Vorgang aber derselbe bleibt. Dann ist eine Union am Parameter die ehrlichere Modellierung.

6:23 Die Faustregel, die ich Ihnen mitgeben möchte: Ergibt sich die Rückgabe aus dem Parameterwert, ist es eine Union mit Unterscheidungsfeld — kein Overload. Oben der berechtigte Fall: zwei Nummerntypen, zwei verschiedene Ergebnisse, zwei echte Aufrufformen. Unten dieselbe Aufgabe als Union, bei der ein Kennzeichnungsfeld sagt, worum es geht.

6:43 Der praktische Unterschied liegt im Rumpf der Funktion, und der ist entscheidend: Die Union lässt sich im Inneren verengen, sodass der Compiler Sie durch beide Fälle führt. Der Overload nicht — er verlangt eine Implementierung, die beide Formen gleichzeitig bedient, und die öffnet in der Praxis fast immer eine Hintertür.

7:02 Deshalb die Empfehlung: Union zuerst versuchen, Overload nur, wenn es wirklich zwei Vorgänge sind. Vier Prüffragen, die Sie an jede Signatur anlegen können. Ergibt sich der Rückgabetyp aus den Parametern und nicht aus irgendeinem Kontext? Ist wirklich kein Parameter nur deshalb optional, weil ein Aufrufer ihn selten braucht? Stehen die Fehlerfälle in der Signatur statt in der Dokumentation?

7:26 Und die schärfste Frage zum Schluss: Liest sich die Signatur ohne den Rumpf verständlich? Wenn Sie den Code lesen müssen, um den Aufruf zu verstehen, hat die Signatur ihre Aufgabe verfehlt. Sie ist der Vertrag — und einen Vertrag liest man, ohne den Betrieb zu besichtigen. Der erste Punkt ist der stille Totalschaden: Overloads mit einer Implementierungssignatur, die intern alles öffnet.

7:49 Nach außen sieht die Funktion sauber aus, innen ist jede Prüfung abgeschaltet. Der zweite ist Alltag: optionale Parameter aneinanderreihen, bis beim Aufruf die Reihenfolge geraten wird — spätestens beim vierten übergibt jemand etwas an der falschen Stelle. Und der dritte: eine Funktion gibt nichts zurück, obwohl der Aufrufer ein Ergebnis bräuchte, und holt es sich dann über einen Umweg.

8:11 Alle drei verstecken Information, die in die Signatur gehört.

Optional und schreibgeschützt

8:16 Jetzt kommt ein Kapitel über drei Wörter, die im Alltag ständig als Synonyme benutzt werden, obwohl sie drei ganz verschiedene Dinge bedeuten. Wer sie sauber auseinanderhält, modelliert präziser — und erkennt später sofort, wenn generierter Code sie durcheinanderbringt. Das tut er nämlich zuverlässig. Drei Aussagen, drei Bedeutungen. Optional heißt: Die Eigenschaft darf ganz fehlen. Nullable heißt: Sie ist da, aber ohne Inhalt.

8:42 Und schreibgeschützt heißt: Sie ist da und darf nach der Erzeugung nicht mehr geändert werden. Denken Sie an ein Formular: Ein Feld, das gar nicht gedruckt ist. Ein Feld, das gedruckt, aber leer ist. Und ein Feld, das ausgefüllt und mit Kugelschreiber geschrieben wurde. Drei völlig verschiedene Situationen — und alle drei werden im Code routinemäßig durcheinandergebracht. Jede davon ist eine fachliche Aussage, keine technische Feinheit.

9:11 Drei Zeilen in einem Auftrag, und jede sagt etwas anderes. Die Nummer ist immer da und wird nie geändert — sie identifiziert den Auftrag, ein Wechsel wäre fachlich Unsinn. Die Abholnotiz darf ganz fehlen, denn oft gibt es keine. Und der Betrag ist da, kann aber noch leer sein, weil er erst nach der Prüfung feststeht. Wichtig ist der Hinweis unten: Ohne eine zusätzliche Compileroption bedeutet das Fragezeichen beides zugleich — fehlend oder leer.

9:38 Das ist der Grund, warum sich diese Unterscheidung im Code oft nicht so klar zeigt, wie sie fachlich gemeint war. Diese Tabelle räumt mit einem verbreiteten Missverständnis auf. „Wir sind strict" klingt nach vollständiger Strenge, ist es aber nicht. Die beiden oberen Optionen gehören dazu und sind seit Version 6.0 ohnehin voreingestellt.

9:58 Die beiden unteren nicht — und ausgerechnet die haben es in sich: Die eine trennt „fehlt" sauber von „ist leer", die andere sorgt dafür, dass ein Zugriff über einen Index auch ins Leere greifen kann. Beides ist wahr, beides prüft niemand von allein. Wenn Sie das nächste Mal hören, ein Projekt sei strikt konfiguriert, fragen Sie ruhig nach, welche Strenge gemeint ist.

10:20 Der mittlere Punkt verdient eine Warnung: Die Option für geprüfte Indexzugriffe im Bestand nebenbei anzuschalten, ist kein Handgriff, sondern ein Vorhaben — sie erzeugt in gewachsenem Code schnell dreistellige Fehlerzahlen. Sinnvoll ist sie trotzdem, nur eben geplant. Und der letzte Punkt ist ein klassisches Missverständnis: Schreibschutz an einer Eigenschaft ist keine Unveränderlichkeit.

10:42 Er schützt die Eigenschaft, nicht das Objekt dahinter — eine geschützte Referenz auf eine Liste verhindert nicht, dass die Liste verändert wird.

any, unknown, never und void

10:50 Und jetzt kommt der wichtigste Unterschied im ganzen Typsystem. Ich fasse ihn vorweg in einem Satz zusammen, den Sie mitnehmen sollten: any schaltet die Prüfung ab, unknown erzwingt sie. Wer nur diesen Satz aus dem Modul behält, hat schon die Hälfte verstanden. Vier Typen, die alle irgendwie „unbestimmt" heißen und doch gegensätzlich wirken. Der erste sagt: prüf hier nichts mehr.

11:13 Er ist fast nie richtig, allenfalls als sichtbarer Zwischenschritt während eines Umbaus. Der zweite sagt: irgendetwas, aber prüf es erst — und der gehört an jede Grenze, an der Daten von außerhalb des Programms hereinkommen. Der dritte beschreibt einen Fall, der nicht eintreten kann; er ist das Werkzeug für Vollständigkeitsprüfungen und begegnet uns in Modul 3 wieder.

11:35 Und der vierte sagt schlicht: gibt nichts zurück. Vier Aussagen, die man nicht verwechseln sollte — die beiden ersten am allerwenigsten. Sehen Sie sich an, was diese Funktion erzwingt. Der Parameter ist unbestimmt, also können Sie mit ihm zunächst überhaupt nichts anfangen — kein Feldzugriff, keine Weitergabe. Der einzige Weg nach vorn führt durch die Prüfung, und erst danach steht dort ein richtiger Auftrag.

11:59 Der Compiler zwingt Sie nicht zu einer bestimmten Prüfung, aber er zwingt Sie dazu, überhaupt eine zu haben. Und jetzt der Vergleich: Mit dem abschaltenden Typ an derselben Stelle übersetzt der Code genauso — nur bricht er dann beim ersten unpassenden Datensatz im Betrieb, an einer ganz anderen Stelle, Wochen später. Vier Gründe, und der letzte ist der unterschätzte. Ein unbestimmter Wert lässt sich nicht versehentlich benutzen, nur bewusst prüfen.

12:26 Der Weg zum Domänentyp führt zwangsläufig durch eine Prüfung — sie ist nicht optional. Diese Prüfstelle steht sichtbar im Code und kann deshalb im Review beurteilt werden. Und nun der vierte: Der abschaltende Typ breitet sich aus. Was er berührt, wird ebenfalls ungeprüft, und zwar leise. Ein einziges davon an der falschen Stelle kann einen ganzen Datenpfad entkernen, ohne dass irgendjemand eine Warnung sieht.

12:51 Der erste Punkt ist die häufigste Sünde überhaupt: die Prüfung abschalten, um eine Fehlermeldung loszuwerden. Der Fehler ist damit nicht weg, er ist vertagt — und er kommt später wieder, teurer. Der zweite ist die elegantere Variante desselben Fehlers: einen unbestimmten Wert per Behauptung in den Zieltyp zwingen, statt ihn zu prüfen. Sieht besser aus, wirkt genauso.

13:12 Und der dritte ist eine Feinheit: „gibt nichts zurück" ist nicht dasselbe wie „gibt einen leeren Wert zurück" — der eine Typ macht eine Aussage über die Absicht, der andere über den Wert.

Structural Typing und seine Folgen

13:23 Jetzt eine Eigenschaft von TypeScript, die vieles erklärt, was zunächst überrascht: Der Compiler vergleicht Typen nach ihrer Struktur, nicht nach ihrem Namen. Das ist meistens praktisch — und in genau einem Fall gefährlich. Diesen Fall sehen wir uns an, und in Modul 5 lösen wir ihn. Zwei Typen sind für TypeScript austauschbar, wenn ihre Struktur zusammenpasst. Ihr Name spielt keine Rolle.

13:47 Ein Bild: Ein Schlüssel passt ins Schloss, wenn die Zacken stimmen — was auf dem Anhänger steht, interessiert das Schloss nicht. Das erklärt viele überraschende Zuweisungen, die problemlos durchgehen, und es hat eine unangenehme Folge: Drei fachlich völlig verschiedene Kennungen lassen sich munter vertauschen, solange alle drei Zeichenketten sind.

14:06 Der Compiler sieht dreimal dieselbe Zackenform. Dass die eine einen Kunden meint und die andere einen Auftrag, weiß nur der Mensch. Hier steht der Fehler in aller Ruhe im Code, und der Compiler sagt kein Wort. Eine Kundennummer wird einer Auftragsnummer zugewiesen — fachlich blanker Unsinn, technisch völlig in Ordnung. Der Grund steht in der Fußzeile und ist wichtig genug, ihn auszusprechen: Ein Typalias auf eine Zeichenkette erzeugt keinen eigenen Typ, sondern nur einen zweiten Namen für denselben.

14:36 Sie haben also nichts abgesichert, sondern nur Dokumentation geschrieben, die aussieht wie eine Absicherung. Das ist die gefährlichere Variante von gar nichts. Wie man daraus wirklich eigenständige Typen macht, zeigt Modul 5. Über diese Frage sind schon ganze Abende in Entwicklerrunden verstrichen, und das lohnt sich selten.

14:55 Die Tabelle zeigt, worin sie sich wirklich unterscheiden: Objektformen können beide, aber Unions, Tupel und alles Bedingte kann nur das Alias. Und Interfaces sind nachträglich erweiterbar, also offen — was manchmal gewünscht ist und manchmal genau nicht. Unsere Empfehlung im Seminar ist pragmatisch: Interfaces für öffentliche Objektformen, Aliase für alles Übrige.

15:17 Wichtiger als die Wahl ist, dass Sie im Projekt eine treffen und dabei bleiben. Der erste Punkt ist der, den wir gerade gesehen haben, und er ist der einzige mit echten Folgen: Typaliase auf Zeichenketten für eigenständige Typen zu halten. Der zweite ist eine Warnung vor Zeitverschwendung — die Frage Interface oder Alias für wichtig zu halten. Sie ist es selten.

15:38 Und der dritte betrifft den Sonderfall: Die offene Erweiterbarkeit von Interfaces ist eine echte Eigenschaft. Wo sie unerwünscht ist, etwa an einer scharf abgegrenzten öffentlichen Schnittstelle, sollte man sie kennen und meiden.

readonly, as const und Literal Types

15:52 Jetzt wird es richtig nützlich. In diesem Kapitel drehen wir die übliche Richtung um: Statt Typen zu schreiben und Werte daran zu messen, lassen wir aus den Werten die Typen entstehen. Das spart doppelte Pflege — und ist die Grundlage für die Unions, mit denen Modul 3 arbeitet. Ein Literal Type verengt einen Wert auf genau sich selbst: nicht irgendeine Zeichenkette, sondern diese eine.

16:15 Und mit einer kleinen Ergänzung lässt sich ein ganzes Objekt oder eine ganze Liste so behandeln — die Werte werden literal, die Struktur wird schreibgeschützt. Der eigentliche Gewinn kommt danach: Aus einer solchen Liste lässt sich eine Union ableiten, statt sie ein zweites Mal von Hand zu pflegen. Und alles, was man nur einmal pflegt, kann nicht auseinanderlaufen. Das ist einer der wenigen Kunstgriffe, die wirklich jeden Tag etwas bringen.

16:40 Vergleichen Sie die beiden Fassungen. Oben eine gewöhnliche Liste von Filialnamen — ihr Typ ist „irgendwelche Zeichenketten", jeder beliebige Text würde passen. Unten dieselbe Liste mit dem kleinen Zusatz, und plötzlich kennt der Compiler die einzelnen Namen. Die Zeile darunter macht daraus einen Typ, der genau diese Filialen erlaubt und sonst nichts.

17:01 Und jetzt der eigentliche Gewinn: Kommt morgen eine Filiale dazu, ändert sich der Typ automatisch mit. Wert und Typ können nicht mehr auseinanderlaufen, weil es nur noch eine Quelle gibt. Vier Wirkungen. Die Liste steht einmal im Code statt zweimal — als Wert und noch einmal als Typ. Ein Tippfehler in einem Filialnamen wird zum Übersetzungsfehler statt zu einem leeren Suchergebnis irgendwann im Betrieb.

17:25 Die abgeleitete Union ist die Grundlage für die unterscheidbaren Unions aus Modul 3, mit denen wir Zustände modellieren. Und der Schreibschutz macht sichtbar, dass diese Liste nicht zur Laufzeit wächst — eine Information, die sonst nirgends steht. Vier Gewinne für ein Schlüsselwort. Selten ist der Aufwand-Nutzen-Schnitt so eindeutig.

satisfies für überprüfte Konfigurationen

17:45 Zum letzten Werkzeug dieses Moduls. Es löst ein Problem, das jeder kennt, aber kaum jemand benennen kann: Man möchte prüfen, ob eine Konfiguration vollständig ist — verliert dabei aber genau die Genauigkeit, wegen der man den Wert überhaupt hingeschrieben hat. Der Unterschied zur gewöhnlichen Annotation ist der ganze Punkt. Beide prüfen den Wert gegen einen Typ.

18:07 Aber die Annotation wirft danach die genauere Information weg — der Wert gilt fortan nur noch als das, was Sie angegeben haben. Das neuere Schlüsselwort prüft ebenfalls, behält den abgeleiteten, engeren Typ aber bei. Ein Bild: Der Prüfer schaut sich Ihre Sendung an und bestätigt, dass alles Vorgeschriebene drin ist — er packt aber nicht alles in eine Einheitskiste um.

18:28 Genau das braucht man bei Konfigurationsobjekten: Prüfung und Genauigkeit zugleich. Hier eine Konfiguration der Werkstattplätze je Filiale. Die Prüfung sorgt dafür, dass keine Filiale fehlt — vergessen Sie eine, meldet es der Compiler sofort. Und die letzte Zeile zeigt den Gewinn: Der Zugriff auf eine konkrete Filiale ist weiterhin genau, der Compiler kennt die Schlüssel.

18:51 Mit einer gewöhnlichen Annotation an derselben Stelle wäre die Prüfung ebenfalls gelaufen, aber die Schlüssel wären danach verloren — jeder erfundene Name hätte sich abfragen lassen. Prüfen ohne zu verlieren: Das ist der ganze Trick, und er kostet ein Wort. Vier Situationen, und alle haben dieselbe Form: eine feste Menge von Fällen, die vollständig abgedeckt sein muss. Konfigurationen, die alle Fälle einer Union bedienen.

19:17 Tabellen von Handlern, bei denen jeder Zustand einen Eintrag braucht — sonst läuft irgendwann einer ins Leere. Übersetzungsdateien und Funktionsschalter mit festen Schlüsseln. Kurz: überall dort, wo Vollständigkeit und Genauigkeit zugleich gefragt sind. Wenn Sie in Ihrem Projekt eine solche Tabelle finden, ist das der beste Ort, um damit anzufangen.

19:40 Der erste ist der klassische Anfängerfehler und macht den Gewinn zunichte: beides gleichzeitig setzen — Annotation und Prüfung. Dann gewinnt die Annotation, die Genauigkeit ist weg, und Sie haben nur ein Wort mehr geschrieben. Der zweite ist grundsätzlicher: Das Ganze prüft beim Übersetzen, nicht zur Laufzeit. Es ersetzt keine Validierung eingehender Daten — wir sind weiterhin auf der Compilerseite.

20:03 Und der dritte: den Gewinn gar nicht nutzen und hinterher doch wieder mit Behauptungen arbeiten.

Übung — Domänentypen statt loser Daten

20:09 Jetzt setzen Sie das zusammen. Wir nehmen lose Auftragsdaten und modellieren sie so, dass der Compiler fachliche Unmöglichkeiten abweist. Das Ergebnis der Übung sind nicht schönere Typen — es ist die Liste dessen, was danach nicht mehr eingegeben werden kann. Das Lernziel lautet: fachliche Aussagen in Typen ausdrücken, sodass unmögliche Zustände gar nicht mehr darstellbar sind.

20:32 Das ist etwas anderes, als sie zu verbieten — sie sollen sich nicht einmal hinschreiben lassen. Erfolgreich sind Sie, wenn der Compiler mindestens drei zuvor mögliche Falscheingaben abweist, und keine davon per Behauptung umgangen wurde. Wer früh fertig ist, schaltet die Option für exakte Optionalität ein und prüft, welche Optionalität im Modell eigentlich nur behauptet war.

20:54 Diese Frage bringt in fast jedem Bestand etwas zutage. Der rote Faden der fünf Schritte ist ein Fragebogen. Zuerst lesen Sie das Modul und notieren jede lose Zeichenkette und jede lose Zahl — das sind die Kandidaten. Dann stellen Sie an jedes Feld dieselben drei Fragen: Darf es fehlen? Darf es leer sein? Darf es sich ändern?

21:15 Feste Wertelisten machen Sie anschließend zur Typquelle, Konfigurationen prüfen Sie auf Vollständigkeit. Und im letzten Schritt kommt der Lohn: Sie probieren aus, welche Falscheingabe der Compiler jetzt abweist. Auch hier gilt: keine Behauptungen. Wer eine bräuchte, notiert die Stelle — sie ist Material für Modul 3 oder Modul 6.

21:36 Vier Sätze zum Mitnehmen. Ableiten ist der Normalfall, annotieren die bewusste Ausnahme — und begründungspflichtig. Unbestimmte Werte an jeder Grenze, die abschaltende Variante nirgends; dieser eine Unterschied trägt das ganze Seminar. Strenge ist zwar voreingestellt, deckt aber nicht alle Strenge ab — fragen Sie im Zweifel nach, welche gemeint ist.

21:57 Und die Werkzeuge für Literale und geprüfte Konfigurationen halten Wert und Typ dauerhaft zusammen. Im nächsten Modul bringen wir Bewegung hinein: Wie modelliert man Zustände, die sich ändern — und wie führt einen der Compiler durch alle Fälle?