Erkennung von totem Code in einem alten C/C++-Projekt

Question

Wie würden Sie die Erkennung von totem Code in C/C++-Code angehen? Ich habe eine ziemlich große Codebasis, mit der ich arbeiten muss, und mindestens 10-15 % sind toter Code. Gibt es ein Unix-basiertes Werkzeug, um diese Bereiche zu identifizieren? Einige Teile des Codes verwenden immer noch viel Präprozessor, kann ein automatisierter Prozess das bewältigen?

Answer 1

Dazu können Sie ein Tool zur Analyse der Codeabdeckung verwenden und nach ungenutzten Stellen in Ihrem Code suchen.

Ein beliebtes Werkzeug für die gcc-Toolchain ist gcov, zusammen mit dem grafischen Frontend lcov ( http://ltp.sourceforge.net/coverage/lcov.php ).

Wenn Sie gcc verwenden, können Sie mit gcov-Unterstützung kompilieren, die durch das Flag '--coverage' aktiviert wird. Führen Sie anschließend Ihre Anwendung oder Ihre Testsuite mit diesem gcov-aktivierten Build aus.

Grundsätzlich wird gcc einige zusätzliche Dateien während der Kompilierung ausgeben und die Anwendung wird auch einige Abdeckungsdaten während der Ausführung ausgeben. Diese müssen Sie alle sammeln (.gcdo und .gcda Dateien). Ich werde hier nicht ins Detail gehen, aber Sie müssen wahrscheinlich zwei Umgebungsvariablen setzen, um die Abdeckungsdaten auf eine vernünftige Weise zu sammeln: GCOV_PREFIX und GCOV_PREFIX_STRIP...

Nach dem Lauf können Sie alle Abdeckungsdaten zusammenstellen und sie durch die lcov-Toolsuite laufen lassen. Das Zusammenführen aller Abdeckungsdateien aus verschiedenen Testläufen ist ebenfalls möglich, wenn auch ein wenig kompliziert.

Wie auch immer, am Ende haben Sie eine schöne Reihe von Webseiten, die einige Abdeckungsinformationen zeigen und auf die Codestücke hinweisen, die keine Abdeckung haben und daher nicht verwendet wurden.

Natürlich müssen Sie doppelt prüfen, ob die Codeabschnitte in keiner Situation verwendet werden, und vieles hängt davon ab, wie gut Ihre Tests die Codebasis trainieren. Aber zumindest wird dies eine Vorstellung von möglichen Kandidaten für toten Code vermitteln...

Answer 2

Kompilieren Sie es unter gcc mit -Wunreachable-code.

Ich denke, je aktueller die Version ist, desto besser sind die Ergebnisse, aber vielleicht irre ich mich mit meinem Eindruck, dass sie aktiv daran gearbeitet haben. Beachten Sie, dass es eine Flussanalyse durchführt, aber ich glaube nicht, dass es Ihnen etwas über "Code" sagt, der bereits tot ist, wenn er den Präprozessor verlässt, weil er vom Compiler nie geparst wird. Es wird auch nicht z.B. exportierte Funktionen erkennen, die nie aufgerufen werden, oder Code für die Behandlung von Spezialfällen, die nur deshalb unmöglich sind, weil die Funktion mit diesem Parameter nie aufgerufen wird - dafür brauchen Sie Code Coverage (und führen Sie die Funktionstests aus, nicht die Unit-Tests. Unit-Tests sind angeblich um eine 100%ige Codeabdeckung zu erreichen und somit Codepfade auszuführen, die für die Anwendung "tot" sind). Mit diesen Einschränkungen im Hinterkopf ist es jedoch ein einfacher Weg, um die am meisten verpfuschten Routinen in der Codebasis zu finden.

Dieser CERT-Hinweis listet einige andere Tools zur Erkennung von statischem totem Code auf

Answer 3

Nur für C-Code und unter der Annahme, dass der Quellcode des gesamten Projekts starten Sie eine Analyse mit dem Open-Source-Tool Frama-C . Jede Anweisung des Programms, die in der grafischen Benutzeroberfläche rot angezeigt wird, ist toter Code.

Wenn Sie Probleme mit "totem Code" haben, sind Sie vielleicht auch daran interessiert "Ersatzcode" zu entfernen, also Code, der zwar ausgeführt wird, aber nicht zum Endergebnis beiträgt. Dazu müssen Sie Folgendes bereitstellen eine genaue Modellierung der E/A-Funktionen (Sie möchten nicht eine Berechnung zu entfernen, die scheinbar "überflüssig" ist, aber die als Argument verwendet wird für printf ). Frama-C verfügt über eine Option, mit der Ersatzcode angezeigt werden kann.

Answer 4

Ihr Ansatz hängt von den (automatisierten) Verfügbarkeitstests ab. Wenn Sie eine Testsuite haben, von der Sie glauben, dass sie einen ausreichenden Teil der Funktionalität abdeckt, können Sie eine Abdeckungsanalyse verwenden, wie bereits in früheren Antworten vorgeschlagen.

Wenn Sie nicht so viel Glück haben, sollten Sie sich mit Quellcode-Analysetools wie SciTools ' Verstehen, das Ihnen bei der Analyse Ihres Codes mit Hilfe zahlreicher integrierter Analyseberichte helfen kann. Meine Erfahrungen mit diesem Tool liegen 2 Jahre zurück, daher kann ich Ihnen nicht viele Details nennen, aber ich erinnere mich an einen beeindruckenden Support mit sehr schnellen Durchlaufzeiten für Fehlerbehebungen und Antworten auf Fragen.

Ich habe eine Seite gefunden auf statische Quellcode-Analyse die auch viele andere Tools auflistet.

Wenn Ihnen auch das nicht ausreichend hilft und Sie speziell daran interessiert sind, den toten Code im Zusammenhang mit dem Präprozessor herauszufinden, empfehle ich Ihnen, mehr Details über den Code zu posten. Wenn es zum Beispiel hauptsächlich mit verschiedenen Kombinationen von #ifdef-Einstellungen zusammenhängt, könnten Sie Skripte schreiben, um die (Kombinationen von) Einstellungen zu bestimmen und herauszufinden, welche Kombinationen nie tatsächlich gebaut werden, usw.

Answer 5

Beide Mozilla y Offenes Büro haben selbst entwickelte Lösungen.