Flutter / Dart Null Safety Migration
Vor wenigen Tagen erschien im Rahmen des Flutter 2.0 bzw. Dart 2.12 Releases der stabile Null Safety Support für Dart. Entsprechend begab ich mich gestern Abend das erste Mal auf den Migrationspfad und aktualisierte meine kleine Anwendung zur Auswertung von Statistiken. Selbige nutze ich produktiv zum erfassen der Nutzerzahlen hier im Blog und auch um die monatlichen Top 10 Listen zu erstellen.
Die Migration ist sehr gut dokumentiert open_in_new und was extrem großartig ist, ist der dart migration Befehl, welcher versucht ein Projekt ohne Null Safety für euch anzupassen. Dabei erhält man einen geführten Prozess, bei welchem ihr die Liste der geplanten Änderungen auf einer interaktiven lokalen Website zu sehen bekommt und dort noch weitere Anpassungen vornehmen könnt. Meiner Meinung nach ist dieses Tool im Kontext der Migration eine glatte Eins mit Sternchen.
Nachdem ausführen der Migration für das kleine Projekt mit ca. 1000 Zeilen reinem Code, blieb tatsächlich nur eine Stelle an der ich manuell Hand anlegen musste. Die App lief anschließend ohne Probleme und weiterer Aufwand war nicht nötig. Hier kommt nun aber eine Empfehlung, die mehr Arbeit bedeutet, selbige meiner Meinung nach aber wert ist.
Null Safety bietet wie der Name schon sagt ein neues Level an Sicherheit gegen bestimmte Fehler. Auch wenn eure App läuft, so eine Migration ist ein guter Moment eure Flows und die Codequalität zu überprüfen. Mein Startpunkt für diese Optimierungen waren alle Fields in Klassen die als Nullable markiert wurden. Durch ein kleines Refactoring konnte nicht 50 – 70% dieser Fields Null Safe machen und so Fehlern aus dem Weg gehen. Denn oft ist ein Default-Wert oder eine immer gegebenen Initialisierung durch den Konstruktor möglich und sogar besser für das eigentliche Programm.
Im zweiten Schritt überprüfte ich alle ! Modifier, denn selbige sagen Dart das ein Wert welcher Null sein kann, an der markierten Stelle auf jeden Fall nicht Null ist. Falsch verwendet sorgt dieses Ausrufezeichen also dafür, dass man im Prinzip Quick & Dirty alles zum kompilieren bringen kann, aber dafür jegliche Vorteile von Null Safety verliert. Im Rahmen meiner Überprüfung schaute ich mir meine Flows an und passte den Code an, sodass ich diverse ! Modifier entfernen konnte. Damit verbunden machte ich Variablen, Parameter und Return-Values Non-Nullable und behandelte eventuelle Null Vorkommnisse explizit in den jeweiligen Situationen.
Mit diesen genannten Anpassungen, die durchaus trivial und kurzweilig klingen, kann man sich bei größeren Projekten länger aufhalten, da sie oft mit einem Rattenschwanz an Folgeanpassungen verbunden sind. Aber es lohnt sich, denn selbst bei meinem kleinen Beispiel überdachte ich den Ablauf der Logik an einigen Stellen, verhinderte dadurch zukünftige Fehler und optimierte sogar etwas die User Experience und Performance.
Es schadet bekanntlich ohnehin nie ein zweites Mal über Dinge nachzudenken, aber die Null Safety Migration bietet euch einen spezifischen Punkt dies zu tun und markiert sogar einen Teil der Orte wo ein zweiter Gedanke gut platziert sein könnte. Insofern kann ich nur sagen, nutzt die Chance bei der Null Safety Migration eure Code Qualität zu verbessern und ärgert euch nicht über den Mehraufwand. Als jemand der viele Jahre mit Java gearbeitet hat und nun auf Kotlin gewechselt ist - mit Null Safety - kann ich nur sagen, es ist den Aufwand wert.