© Ozz Design/Shutterstock.com
Best Practices für Typsicherheit

Teststrategie mit Hilfe der statischen Analyse


Wenn wir eine Anwendung entwickeln, ist es unser Ziel, dass die Software das tut, was sie tun soll. Gleichzeitig muss die Anzahl der Fehler und Ausfälle so klein wie möglich bleiben. Gegen äußere Umstände, die diesem Ziel entgegenstehen, etwa kurze Deadlines oder sich verändernde Anforderungen, sollten wir uns absichern. Helfen kann dabei die Nutzung eines Typsystems im Verbund mit einem statischen Analysetool.

Dieser Artikel beleuchtet das Konzept der Typsicherheit und zeigt, wie es die Zuverlässigkeit und Stabilität des Codes verbessert. Sobald Ihr Code typsicher ist und diese Tatsache durch automatisierte Tools verifiziert wurde, können Sie selbst entscheiden, welche Teile einer Anwendung umfangreiche Unit-Tests benötigen und wo Sie sich auf klar definierte Typen verlassen können.

Typsystem – warum eigentlich?

Mit einem Typsystem kommuniziert man klar und deutlich, welche Arten von Werten durch den Quellcode transportiert werden. Ob nun int, float, string oder boolean – klar ist, dass wir nicht alle Werte gleich behandeln können. Deshalb gilt: Je mehr wir über die Werte wissen, die durch den Code wandern, desto besser. Wer bisher noch keine Typhinweise eingesetzt hat, kommt durch das Hinzufügen von Informationen, ob eine Variable nun int, float, string oder boolean als Wert akzeptiert, schon sehr weit. Wenn nun aber eine Funktion beispielsweise nur Integers akzeptiert, gilt das wirklich für jeden Integer? Oder nur für positive ganze Zahlen? Oder ist nur eine begrenzte Menge von Werten sinnvoll, wie Stunden an einem Tag oder Minuten in einer Stunde?

Eines ist offensichtlich: Mögliche Eingaben auf sinnvolle zu beschränken, reduziert unerwünschtes Verhalten. Wer diesen Ansatz verfolgt, kommt schnell zu der Idee, die eigenen Objekte mit Typhinweisen zu versehen. Die Vorteile liegen auf der Hand: Wir wissen dadurch nicht nur, was wir einer Funktion übergeben können, sondern auch, welche Operationen (Methoden) ein Objekt anbietet. Dabei will ich nicht behaupten, dass skalare Werte niemals ausreichen und stattdessen immer Objekte verwendet werden sollten. Doch sollte man sich immer fragen, wenn man dabei ist, einen String zu typisieren, ob nicht bei der Eingabe etwas schiefgehen könnte. Möchte ich einen leeren String zulassen? Was ist mit Nicht-ASCII-Zeichen?

Anstatt nun aber Validierungslogik in eine Funktion zu packen, die etwas mit einem skalaren Wert macht, ist es besser, ein spezielles Objekt zu erzeugen und die Validierungslogik in seinen Konstruktor...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang