Bei einem Sourcecode, der bereits vorliegt, nehme ich erst einmal eine Analyse vor. Nach dem Ergebnis der Analyse geht es dann weiter mit Aufräumen und Vereinfachen. Erst danach beginnt die Fehlersuche oder Erweiterung der Software. Nur wenn es ausschließlich um eine Software Wartung geht, kommt danach direkt der Test.
Aufräumen
Als erstes schaue ich nach Funktionen, Variablen und Macros, die nirgendwo benutzt werden. Damit wird die Übersicht schon einmal deutlich besser. Im Beispiel mit dem JSON Parser liegt hierzu nichts vor. Das Nächste ist dann die Untersuchung mit Secure Programming Lint. Der erste Durchlauf von jsmn.c endet mit 44 Warnungen. Die meisten sind Zuweisungen zwischen signed und unsigned Variablen. Danach folgen ‚incompatible types‘ und noch einige andere Warnungen. Wendet man SPLint das Erstemal an, ist es notwendig, sich das Handbuch, das mitgeliefert wird, genau durchzulesen. Alle Warnungen sind darin beschrieben, wenn auch nicht immer sofort zu verstehen. Nach und Nach korrigiere ich dann die Warnungen, bis nach dem letzten Durchlauf keine mehr auftaucht. Hiernach ist schon einmal der erste Test nötig, ob alles noch so funktioniert wie vorher. Wenn es um Fehlerkorrekturen geht, schaue ich auch schon einmal, ob nicht bereits einige der gemeldeten Fehler verschwunden sind, was meistens der Fall ist.
Anschliessend, wenn man ein passendes Tool dafür hat, kann man noch auf die Einhaltung von MISRA Regeln überprüfen. Hierzu gibt es, nach meinem Wissen, noch kein freies Tool.
Anschließend wird der Source Code in der Software Konfiguration ( z.B. Subversion ) mit einem entsprechendem Kommentar ‚committed‘.
Vereinfachen
Hier kommen die Ergebnisse der Analyse mit dem Tool CCCC zum Tragen. Wichtige Parameter sind die Komplexität nach McCabe und die Länge der Funktionen in LoC ( Lines of Code ). Ist die Komplexität eher hoch, dann empfiehlt sich diese durch Aufteilen in z.B. Unterfunktionen zu verringern. Wenn die Funktion zu lang ist, z.B. länger als auf dem Bildschirm zu Übersehen, dann gilt auch hier das Zerlegen in mehrere Teilfunktionen, um die Übersichtlichkeit zu verbessern. Das nimmt etwas Zeit in Anspruch, auch für die anschließenden Tests.
Schließlich wird der Source Code in der Software Konfiguration ( z.B. Subversion ) mit einem entsprechendem Kommentar ‚committed‘.
Refactoring
Für weitere Maßnahmen, die Komplexität herunter zu bekommen, ist ein Refactoring der Sourcen angesagt. Dazu gibt es in einigen Entwicklungsumgebungen wie z.B. Eclipse bereits integrierte Hilfsmittel.
Nach den anschließenden Tests wird der Source Code in der Software Konfiguration ( z.B. Subversion ) mit einem entsprechendem Kommentar ‚committed‘.
Literaturhinweise
Martin Fowler / Kent Beck
– Refactoring: Improving the design of Existing Code
Henry David Thoreau
– Walden (englischsprachige Ausgabe)
– Walden oder Leben in den Wäldern (deutschsprachige Ausgabe)
