Category

Neulich bei der Code-Review in einem Angular-Team (ein fiktiver Dialog):

READ MORE

Beim Schreiben von Software werden Fehler gemacht. Diese Fehler werden – wenn überhaupt – auf unterschiedlichste Art und Weise entdeckt. Ein Verfahren ist die statische Code-Analyse. Diese unterzieht den Code bestimmten formalen Prüfungen. Die zu prüfenden Regeln sind in der Coding Guideline festgehalten. Coding Guidelines sind in der Softwareentwicklung weit verbreitet – wobei ihr Reifegrad von gut bis nicht anwendbar reicht. Damit steht und fällt auch die Akzeptanz bei den Entwickler*innen. Doch auch gute Coding Guidelines stossen nicht immer auf Gegenliebe.

Coding Guideline als Last

Coding Guidelines können eine Last sein, bspw. wenn für deren Überprüfung kein geeignetes Tool verwendet wird. Im Optimalfall sollte es wie ein Rechtschreibeprogramm schon während der Eingabe mögliche Fehler markieren und Verbesserungsvorschläge anbieten. Es wird schnell klar, die eigentliche Last ist meistens die Prüfung auf Konformität mit der Coding Guideline.

Wenn das Tool beispielsweise den Arbeitsfluss unterbricht, wird es schnell an Akzeptanz verlieren. Das gleiche geschieht, wenn schon zu Beginn der Analyse eine Flut von möglichen Defekten angezeigt wird und keine Filtermöglichkeiten bestehen. Im schlechtesten Fall enthält die Coding Guideline viele nicht automatisiert überprüfbare Regeln, die keinem Standard-Regelwerk entsprechen.

Coding Guideline als Nachbrenner

Eine einfache und kurzzyklische Prüfung auf Konformität mit der Coding Guideline wirkt sich sehr positiv auf die Qualität aus. Schliesslich lässt sie sich automatisiert und schnell durchführen – viel schneller als bspw. ein Review. Die Zeitinvestition in die Analyse formaler Implementierungsfehler rechnet sich in den allermeisten Fällen. Vor allem auch deshalb, weil Fehler frühzeitig (vor dem Ausführen) erkannt werden können. Nicht zuletzt erhält der Quellcode ein einheitliches Erscheinungsbild. Kolleg*innen, die in der Zukunft den Code anpassen müssen, werden es den ursprünglichen Autor*innen danken.

Bekannte Programmierrichtlinien

Eine der bekanntesten Programmierrichtlinien ist die MISRA Guideline (Motor Industry Software Reliability Association) aus der Automobilindustrie. Diese ist verfügbar für C und C++. Wobei die «aktuellste» Version für C++ aus dem Jahr 2008 stammt, für C immerhin aus dem Jahr 2012. Eine Aktualisierung ist angezeigt. Dennoch decken die Regeln von MISRA viele bekannte Probleme von C/C++ ab. Nennenswert ist auch das Regelwerk CERT C Coding Standard (vom Computer Emergency Response Team) oder CWE (Common Weakness Enumeration). Wobei letzteres vor allem auf Security-Themen (Gefahren von «ausserhalb der Software»), aber weniger auf Safety-Themen (Gefahren von «innerhalb der Software») eingeht.

Akzeptanz von Coding Guidelines erhöhen

Grundlage für das erfolgreiche Etablieren einer Coding Guideline ist das entsprechende Mindset: sowohl die Entwicklung wie auch das Management müssen anerkennen, das gute Software-Qualität kein Zufallsprodukt ist. Sie verursacht eben auch einen entsprechenden Aufwand. Unterstützt wird die Akzeptanz von Coding Guidelines des Weiteren durch folgende Punkte:

• Neue Coding Guidelines sollten, wenn immer möglich, bottom-up von den Entwickler*innen definiert werden. Sie dürfen sich auch von Team zu Team unterscheiden. Wichtig sind die gemeinsame Basis und die Akzeptanz.
• Zeitbudget für das Pflegen von Software-Qualität und den Wissensaustausch.
• Definieren eines gemeinsamen Style Guides. D.h. das Team definiert das einheitliche Aussehen des Codes. Diese Regeln sollten automatisiert prüfbar sein.
• Kurzzyklische automatisierte Prüfung ermöglichen. Siehe dazu mehr unter Wahl des Tools.

Wahl des Tools – der richtige Treibstoff für die Analyse

Das für das Team und Projekt geeignete Tool verleiht der Prüfung auf Konformität mit der Coding Guideline richtig Schub. Folgende Merkmale sollte das Tool aufweisen, um auf hohe Akzeptanz zu stossen:

• Möglichst für mehrere Programmiersprachen nutzbar
• Verschiedene Regelwerke unterstützen, die anerkannt und weit verbreitet sind (bspw. MISRA, CERT oder CWE).
• Die Möglichkeit bieten, eigene Regeln zu definieren. Dadurch können bspw. auch Regeln betreffend Code Style eingefügt werden.
• Integration möglich ins CI-Tool (Continuous Integration) und in die IDE (Entwicklungsumgebung).
• Unterstützt kollaboratives Arbeiten. Daher meistens browserbasiert, um Defekte gemeinsam im Team zu bearbeiten und zu lösen.
• Unterstützt die offline Prüfung. Wenn der Code zur Überprüfung zuerst eingecheckt werden muss, wird die Prüfrate mit grosser Wahrscheinlichkeit dramatisch sinken. Eine kontinuierliche Prüfung ist unabdingbar, um die technische Schuld gering zu halten.
• Fehler-Severity einstellbar. Wen die Liste möglicher Defekte zu gross ist, kann dies zu einer Geringschätzung und Vernachlässigung des Tools führen. Dies gilt es vor allem bei der Bereinigung von Legacy-Code zu beachten!
• Im regulatorischen Umfeld: zertifiziert nach einer verbreiteten Norm (bspw. IEC 61508 (allg. Industrie – bspw. Automation), ISO 26262 (Automobilindustrie) oder IEC 62304 (Medizintechnik).

Zusammenfassung

Mittels statischer Code-Analyse wird Software auf Konformität mit einer Programmierrichtlinie analysiert. Auf diese Weise werden formale Implementierungsfehler im Code entdeckt. Diese automatisierte Prüfung erfolgt mittels eines Tools. Das Tool sollte kollaboratives Lösen der Defekte unterstützen, möglichst kurzzyklisch nutzbar sein und standardisierte Regelwerke einbeziehen. Ziel ist vor allen Dingen den Arbeitsfluss während der Entwicklung nicht zu unterbrechen.

Coding Guidelines können in der Anwendung einen nicht vernachlässigbaren Aufwand zur Folge haben. Jedoch zahlt sich dieser durch die damit erreichte verbesserte Qualität mehr als aus. Ein weiterer Vorteil liegt in der Einheitlichkeit des Codes in einem grossen Team. Letztendlich vermindert sich auch der Testaufwand erheblich, da viele mögliche Fehler schon vor dem Ausführen behoben werden können.