Statische Code Analyse – Analysieren Sie schon oder debuggen sie noch?

Statische Codeanalyse gehört nicht wirklich zu den Neuheiten in der Softwarewelt. Tools wie PC-Lint sind seit den 80er Jahren im Einsatz und werden in der Industrie durchaus auch häufig verwendet. Für die Verwendung eines solchen Tools spielt es eigentlich keine Rolle ob Firmware für ein Embedded Target oder Software für einen PC entwickelt wird. Trotzdem scheint es oft, dass die statische Code Analyse im Embedded Bereich noch nicht völlig angekommen ist. Viele Firmware-Entwickler scheinen trotz jahrelanger Erfahrung noch nichts von statischer Codeanalyse gehört zu haben. Andere haben von statischer Code Analyse an sich gehört, kennen aber die entsprechenden Tools nicht. Grund genug an dieser Stelle einen kurzen Überblick zum Thema zu geben.

Warum statische Code Analyse?

Jeder, der schon einmal an einer Software geschrieben hat, weiß, dass das Auffinden von Fehlern oft mehr Zeit in Anspruch nimmt als das Schreiben des eigentlichen Codes. Viele Fehler werden bereits durch Compiler Warnungen angezeigt. Trotzdem verbleiben fast immer Fehler im Code. Einige davon machen sich erst im späteren Projektverlauf bemerkbar. In der Regel müssen diese Fehler dann durch zeitaufwendiges Debugging  gefunden werden. Vor allem bei sporadisch auftretenden Fehlern ist dies zum Teil nur schwer möglich.

Die Idee hinter statischer Codeanalyse ist es, automatisiert Fehler zu finden, bevor diese sich überhaupt zur Laufzeit bemerkbar machen. Jeder dabei gefundene Fehler verkürzt die Entwicklungszeit. Allerdings soll davor gewarnt werden, dass auch mit einer statischen Code Analyse kein 100 % fehlerfreier Code entsteht.

Ein weiteres Einsatzgebiet der statischen Code Analyse ist die Überprüfung des Codes in Hinblick auf die Konformität zu Programmierrichtlinien. Viele Tools unterstützen beispielsweise eine Überprüfung nach den MISRA-C Regeln oder können um die eigenen Kodierrichtlinien erweitert werden. Anstatt also nach einem Code Review hunderte von Findings fixen zu müssen, kann der Entwickler regelmäßig den Output der statischen Code Analyse anschauen. Geschieht dies regelmäßig, beginnt der Programmierer irgendwann die Programmierrichtlinien zu verinnerlichen und befolgt diese ganz automatisch.

Welche Tools gibt es

Tools zur statischen Code Analyse gibt es einige. Viele davon sind kostenlos in vollem Umfang erhältlich. In der Regel werden verschiedene Programme für verschiedene Programmiersprachen benötigt. Wikipedia liefert hier einen recht guten Überblick, sortiert nach Programmiersprache. Im Folgenden spreche ich zwei Werkzeuge an, mit denen ich recht gute Erfahrungen gemacht habe. Darüber hinaus gibt es vermutlich noch eine ganze Menge andere Tools mit ähnlicher oder vielleicht sogar besserer Leistung. Alle haben ihre Vor- und Nachteile. Daher empfiehlt es sich unter Umständen auch mehrere Tools parallel zu verwenden. Dies wird sogar zum Teil von den Herstellern der Software empfohlen.

PC-Lint

Bei den kommerziellen Tools zur Analyse von C-Code habe ich persönlich gute Erfahrungen mit dem Klassiker PC-Lint gemacht. Das Tool bietet einen hohen Umfang und ist stark konfigurierbar. So sind u. a. die MISRA-C Regeln enthalten. Dabei lässt sich jede MISRA-C Regel selektiv aktivieren oder deaktivieren. Dies gilt im Übrigen auch für jede andere Regel nach der Lint den Code überprüft. Außerdem bietet Lint verschiedene Möglichkeiten eigene Regeln zu integrieren. So kann mit dem Befehl -deprecate  nach Schlüsselwörtern wie goto gesucht werden. Für jedes goto das Lint findet, kann so eine vom Entwickler spezifizierte Warnung ausgegeben werden. Durch selektives Ein- und Ausschalten von Regeln und dem Implementieren von neuen Regeln lassen sich so die eigenen Kodierrichtlinien zu einem großen Teil integrieren.

Die hohe Komplexität von Lint ist allerdings auch gleichzeitig der größte Nachteil. Es dauert etwas, bis man mit Lint wirklich warm geworden ist. Hat man noch keine Erfahrung mit dem Werkzeug und möchte dieses neu für ein Softwareprojekt aufsetzen, benötigt man schon eine ganze Weile bis das Programm wirklich mit allen gewünschten Regeln reibungslos funktioniert. Vor allem da die Dokumentation des Tools wenig übersichtlich gestaltet ist. Zudem verfügt Lint über keine GUI, sondern ist von Haus aus ein reines Kommandozeilen-Tool. Entwickler können den Workflow hier deutlich verbessern, indem sie Programme in Skriptsprachen wie Python verfassen. Diese können automatisch die Lint-Konfiguration dem eigenen Softwareprojekt anpassen (zum Beispiel setzen der include-Pfade) und das linten aller Dateien vornehmen. Natürlich kostet auch das Schreiben dieser Skripte mitunter viel Zeit.

Cppcheck

Als kostenlose Alternative zur Analyse von C-Code bietet sich unter anderem das Programm Cppcheck an. Der größte Vorteil besteht hier in der einfachen Handhabung. Hat man das Programm installiert, kann man ein neues Cppcheck-Projekt in nur wenigen Minuten einrichten. Die integrierte GUI ist sehr einfach und intuitiv gestaltet, sodass das Lesen von Dokumentation eigentlich nicht nötig ist. Zudem findet auch das Open Source Tool bereits viele Fehler und untersucht den Code ebenfalls nach gewissen Stilregeln. Die Software unterscheidet zwischen vier Level an Ausgaben: Fehler, Warnung, Stilwarnung und Information. Jedes Level lässt sich getrennt ein- und ausschalten. Für Entwickler die bereits bestehenden Code ohne großen Aufwand auf übersehene Fehler überprüfen wollen, bietet sich Cppcheck aufgrund der einfachen Handhabung in jedem Fall an. Hier sollte man sich aber auf Warnungen und Fehler beschränken, da ansonsten der Aufwand zur Untersuchung der Ausgaben sehr zeitaufwendig werden kann.

Fallstricke

Das schlimmste, was man beim Einsatz von statischer Code Analyse tun kann, ist seine Firmware fertig zu entwickeln und zum Schluss „noch mal schnell das Tool drüber laufen lassen und schauen was das noch so findet“. Zum einen wurden so vermutlich viele Fehler durch zeitaufwendige Verfahren – wie Debugging – bereits gefunden, welche mithilfe von statischer Code Analyse deutlich schneller gefunden worden wären. Zum anderen kann es passieren, je nach Konfiguration des verwendeten Tools, dass der Entwickler von der schieren Anzahl an gefunden Fehlern, Warnungen und Informationen geradezu erschlagen wird. Dies passiert vor allem dann, wenn die Verwendung von Kodierstandards wie MISRA-C gefordert sind und durch statische Code Analyse überprüft werden sollen. Lässt der Entwickler nun zu Ende der Entwicklung die statische Code Analyse laufen, können gut hunderte von Warnungen pro Modul auftreten. Hierfür reicht oft schon, dass eine oder zwei Regeln während der Entwicklung übersehen wurden. Für ein ganzes Firmwareprojekt kommt man so schnell auf tausende von Outputs.

Natürlich ist es in der Regel trotzdem eine gute Idee eine bereits fertige Software mittels statischer Code Analyse zu untersuchen. Hierbei sollte man sich allerdings auf „richtige“ Fehler beschränken. Tools wie Cppcheck oder PC-Lint erlauben dazu in der Regel verschiedene „Level“ an Warnungen zu konfigurieren. So unterscheidet PC-Lint z. B. zwischen Fehler, Warnung und Information, welche jeweils aktiviert oder deaktiviert werden können. Hat man die Möglichkeit, empfiehlt es sich allerdings so früh wie möglich Tools zur statischen Code Analyse zu verwenden. Idealerweise sollten die Tools gleich zu Beginn eines Firmwareprojekts eingerichtet werden und in regelmäßigen Abständen immer wieder genutzt werden. Auch eine Automatisierung kann sinnvoll sein. So lassen sich viele Tools z.B. im Prebuild-Prozess des Compilers oder in einem Tool zur Versionsverwaltung integrieren.

Fazit

Aus meiner Sicht gibt es keinen Grund, kein Werkzeug zur statischen Code Analyse zu verwenden. Selbst wenn man der Meinung ist das der eigene Compiler bereits die meisten Fehler ohnehin findet, sind schon kostenlose Tools wie das angesprochene Cppcheck viel zu simpel anzuwenden um diese einfach zu ignorieren. Jedes zusätzliche Tool erhöht mindestens geringfügig die Wahrscheinlichkeit Fehler im eigenen Code aufzudecken, die man ansonsten aufwendig manuell suchen müsste oder die vielleicht sogar ansonsten unbemerkt im Code verbleiben. Komplexere Tools mögen zwar zunächst eine gewisse Zeit zum Einrichten erfordern, hier ist aber zu beachten, dass jeder frühzeitig entdeckte Fehler natürlich auch wieder zu einer Zeitersparnis führt. Nimmt man sich die Zeit ein Tool für ein Projekt einzurichten, kann man die entsprechende Konfiguration ohnehin im Anschluss für jedes weitere Projekt verwenden. Für einen Softwareentwickler lohnt es sich daher in jedem Fall sich mit dem Thema auseinanderzusetzen und verschiedene Tools auszuprobieren. Schon allein, weil die anfangs zuhauf auftretenden und mitunter sehr nervigen Stilwarnungen, zwangsläufig zu einem besseren Programmierstil führen.

Über Feedback und Ergänzungen, z. B. Empfehlungen für weitere Tools und Techniken, würde ich mich sehr freuen.