Erkennung von totem Code und nicht erreichbarem Code

Wie werden toter und nicht erreichbarer Code erkannt?

Die Axivion Suite erkennt Code, der nicht zur Ausführung gelangt, anhand folgender Analysen:

Mittels einer Erreichbarkeitsanalyse auf der Aufruf-Relation (also dem interprozeduralen Kontrollfluss) der analysierten Software findet die Axivion Suite tote Funktionen. Das sind Funktionen, die statisch niemals aufgerufen und damit nicht ausgeführt werden können, weil keine Aufrufpfade von den Einsprungspunkten ins System (also z.B. von main, Interrupt-Handlern oder sonstigen als lebendig markierten Funktionen) aus zu diesen Funktionen existieren.

Mittels tiefergehender Programmanalysen werden auch statisch und von der Programmlogik her unerreichbare Code-Bereiche innerhalb einzelner Funktionen gefunden (unreachable code, dead code, infeasible paths, call defined functions at least once, unreachable return statements, redundant catch block).
Diese Analysen werden von entsprechenden Codierungsregeln genutzt, beispielsweise von den MISRA-Regeln. Ein einfaches Beispiel ist Code direkt hinter einem return-Statement. Ein weiteres Beispiel ist der else-Zweig, der durch die auftretenden Variablenwerte in den beteiligten Bedingungen niemals durchlaufen werden kann. Auch Endlosschleifen lassen sich detektieren.

Lassen Sie sich von totem Code
nicht den Blick verstellen

Code, der im Programmablauf nicht zur Ausführung gelangen wird, benötigt trotzdem Aufmerksamkeit. Toter Code erschwert die Verstehbarkeit, Testbarkeit und die Wartbarkeit. Besonderes Augenmerk sollte daher auf Bereiche gelegt werden, die neuerlich „absterben“ (sterben sie bewusst und können diese Codezeilen entfernt werden?) oder sogar niemals lebendig werden (sollte dieser Code nicht spätestens am Ende eines Sprints lebendig sein?). Diesen Fokus setzt die entwicklungsbegleitende Delta-Analyse der Axivion Suite. Durch dieses direkte Feedback können präventive Bugfixes und niedrigschwellige Refactorings zielgenau geleitet werden.

Sie bauen eine Bibliothek? Sie nutzen Interrupts?

Ein typischer Knackpunkt bei der Analyse toten Codes betrifft Entwickler, die Bibliotheken, Frameworks oder ganze Produktfamilien entwickeln: Die Einsprungspunkte in diesen Fällen sind nicht so klar zu erkennen wie bei einer einfachen Applikation selbst. Je nach Kontext der Fragestellung nach totem Code können daher die „lebendigen“ Anteile mittels verschiedener Konfigurationsmöglichkeiten präzisiert werden. Beispielsweise können APIs angegeben werden, die von der Analyse als „verwendet“ betrachtet werden sollen. Durch Konfiguration der Aufrufmechanismen des Betriebssystems lassen sich die typischen Verwendungen nachbilden, damit die Schnittstellen entsprechend in der Analyse Berücksichtigung finden.

Die Konfigurationsmöglichkeiten sind auch für die Handhabung von Interrupt-Service-Routinen und Interrupt-Handlern nützlich. Hier kann bereits auf der Ebene des Programmcodes (Schlüsselwort interrupt, Nutzung von Attributen) den entsprechenden Funktionen zur Behandlung von Unterbrechungen „Leben eingehaucht“ werden.

Sie programmieren defensiv?

Das Paradigma der defensiven Progammierung ist für die Entwicklung robuster Software äußerst sinnvoll, produziert aus Sicht der statischen Analyse aber oft toten/unerreichbaren Code. Toter Code als solcher wird aber von den üblichen Safety Standards verboten, da er oft auf Fehler in der Programmierung hindeutet – trotzem sind das Code-Anteile, die Sie bewusst nicht entfernen möchten. Daher stehen in der Axivion Suite flexible Konfigurationsmittel bereit, um „bewusst“ toten Code angemessen im Workflow zu markieren und beim Abweichungsmanagement entsprechend zu berücksichtigen.

Das Bild zeigt eine Grafik, die nicht erreichbaren Code darstellt