Wie ich C-Sourcen analysiere

Als erstes nehme ich das Tool Doxygen und erfasse die C-Sourcen  damit. Danach kann ich im Verzeichnis Doxy-Doku, das ich dafür angelegt habe, die Datei index.html im Browser anzeigen (Doppelklick). Jetzt kann ich mir bequem den Call-Tree ansehen  und die Variablen, sowie die Headerstruktur. Damit bekomme  ich schon einmal einen ungefähren Eindruck von der Architektur der vorliegenden Software.

Am Beispiel JSMN Sourcen ohne Calltree: es ist eine einfache Bibliothek.

JSMN-Dateireferenz
Grafik – JSMN-Dateireferenz

Ist eine Dokumentation bereits im Doxygen Format integriert,  kann man sich diese ebenfalls bequem ansehen.

JSMN-Integrierte Doku
Grafik – JSMN-Integrierte Doku

Für die weitere Analyse benutze ich dann das Tool CCCC (C and  C++ Code Counter) und schaue mal, wie es mit der Zeilenanzahl LOC  und der Komplexität nach McCabe der einzelnen Funktionen aussieht.

Am Beispiel JSMN Sourcen:  Eine Übersicht

JSMN-ProjectSummary
Grafik – JSMN-ProjectSummary

Am Beispiel JSMN Sourcen: Ergebnis  der Auswertung.

JSMN-Functions
Grafik – JSMN-Functions

Am Beispiel der Auswertung sieht man schon an der roten  Markierung, das hier die Komplexität etwas zu hoch ist und die  Funktion etwas zu lang. Die gelben Markierungen stehen für  unschön, aber noch nicht kritisch.

Damit wird schon deutlich, wo noch etwas  Verbesserungspotential zu holen ist. Im nächsten Schritt stehen  dann die notwendigen Anpassungen an, um den Sourcecode zu  verbessern und mögliche Fehlerquellen auszumerzen.

Will man noch tiefer einsteigen, dann kann man noch  Codeinspektionen beziehungsweise Codereviews durchführen.

Vor kurzem habe ich einiges zum Thema Sourcecode Analyse gelesen und bin erfreut, das auch andere sich damit befassen. Vor allem das Erstellen von langlebigen Software Architekturen hilft, die weitere Pflege zu vereinfachen. Meistens begegnen mir bereits bestehende Systeme, die angepasst werden müssen. Da ist jede Information hilfreich. Dokumentation ist eigentlich immer knapp bis nicht vorhanden. Da hilft dann nur alles an Informationen einzusammeln, was noch zu finden ist: Beim Service z.B. Service Handbücher etc. , im Intranet, in den Sourcen selbst und bei Entwicklern, die daran beteiligt waren. All diese Informationen sammle ich dann in einem digitalen Notizbuch zusammen mit allen „Forschungsergebnissen“ aus der Analyse. Ob dieses Notizbuch eine Mindmap ist, oder eine einfache Webseite oder ein Wiki, wenn man mit mehreren Leuten daran arbeitet, spielt keine Rolle. Es hängt einfach von den vorhandenen Möglichkeiten ab. Eine genaue Vorgehensweise lässt sich nicht definieren. Es hängt zu vieles von den Umständen ab. Zur Vorgehensweise hilft es sich mit „Modern Heuristics“ zu befassen.

Literaturhinweise und Links

Download von CCCC
http://sourceforge.net/projects/cccc

Graphviz (für Doxygen)
http://www.graphviz.org

Doxygen Homepage
http://www.doxygen.org

Codeinspektion / Codereview
siehe Wikipedia

Arbeiten mit CCCC

Arbeiten mit Doxygen

„Altlasten im Griff“
IX Developer, Heft Januar / Februar 2017

Carola Lilienthal
Langlebige Software Architekturen: Technische Schulden analysieren, begrenzen und abbauen
dpunkt.verlag

Zbigniew Michalewicz, David B. Fogel
How to Solve It: Modern Heuristics
Springer Verlag

Veröffentlicht von

Jürgen

Ich bin Software Ingenieur und habe meine Schwerpunkte in allen Aktivitäten, die zur Software Entwicklung gehören. Am längsten bin ich als Software Entwickler von Embedded Software in C tätig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.