Artikelformat

Die Leiche im Keller finden

Im Lebenszyklus eines Projekts werden immer wieder neue Features gewünscht, entwickelt und angepasst. Mit der Zeit ändert sich auch der Entwicklerstamm und Wissen geht mit den Entwicklern. Somit entsteht ein Bodensatz von Quellcode, den man nicht nutzt. Dabei handelt es sich um toten Code. Diesem rücken wir heute zu Leibe.

Sebastian Bergmann hat wieder einmal ein interessantes Tool geschaffen. Es nennt sich phpdcd und sucht im PHP Code die toten Stellen. Dieses nennt sich phpdcd (php dead code detector).

Installation:

Um das Programm zu nutzen muss man es erst einmal installieren. Dies kann man per PEAR erledigen:

1
2
3
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear install phpunit/phpdcd-beta

Benutzung:
Jetzt kann man das Programm auch schon per phpdcd aufrufen. Der Aufruf erwartet ein Verzeichnis und kann auch rekursiv durch alle Unterverzeichnisse iterieren. Als Ausgabe erhält man eine Liste von Dateien, die möglicherweise verwaisten Code enthalten. Diese Liste muss ein Entwickler beurteilen und die gefundenen Stellen möglicherweise bearbeiten.

Diese Sichtung durch einen Entwickler ist aufgrund gewisser Einschränkungen und Besonderheiten von PHP notwendig. So kann diese statische Analyse bspw. keine Elemente erkennen die während der Laufzeit definiert werden oder Variable Klassennamen.

Aktuell kann phpdcd auch noch keine xml Ausgabe, die in einem CI-Server verarbeitet werden könnte. Weiter habe ich auch noch kein Hudson-Plugin entdeckt, das den java dcd auswertet.

6 Kommentare

  1. Christoph Luehr

    28/10/2010 @ 00:01

    Herr Bergmann rockt 😉

    „In real life“ gibt es leider oft Probleme, das Tool aussagekraeftig einzusetzen: Sobald man einen Dispatcher bzw. ein generisches URL Routing verwendert, findet phpdcd alle „Action“ Methoden als Dead Code – ausschliessen kann man die entsprechenden Klassen aber auch nicht, da dann anderer Code natuerlich fuer tot erklaert wird. Ein aehnliches Problem gibts dann beim Ueberpruefen von Libraries und Modulen.

    Gibts hier Loesungen dazu? Vielleicht sollte man Dummies schreiben, die quasi die entsprechenden Methoden White-listen? Mich wuerden dazu wirklich gerne Ansaetze interessieren.

    Antworten
    • Ich glaube fast, dass eine 100%ig korrekte dcd Analyse das Halteproblem lösen könnte. Von daher muss es Schlupflöcher geben, sonst wäre die theoretische Informatik auf dem Holzweg 🙂

      Weiter ist das von dir beschriebene Problem sicherlich auf die Variablen Klassen zurückzuführen. Aber ich denke, man könnnte den Dispatcher und die Actions getrennt analysieren. Das würde vielleicht einen kleinen Vorteil bringen. Dann sind die Klassen der Actions nicht mehr im Scope des Dispatchers und vice versa und in ihrem eigenen Bereich könnte die Aussage des dcd etwas klarer sein.

      Code nur wegen der „Unzulänglichkeit“ einer statischen Analyse zu schreiben ist mE problematisch, denn dieser wird sicher bei der Wartung und Weiterentwicklung in Vergessenheit geraten und irgendwann selbst als Dead Code gekennzeichnet werden. Auf weitere Ideen bin ich gespannt und wäre mal in der Mittagspause darüber nachdenken 🙂

  2. @Norbert: Ich denke, dass das Tool lediglich überprüft, ob die Methoden/Funktionen im Quelltext auftauchen. Jedenfalls wird das Tool entweder fehlerhaft oder unvollständig sein – ansonsten könnte man in der Tat das Halteproblem lösen. 😉

    Meiner Meinung nach solle man den Code so schreiben, dass man sich statischer Analyse bedienen kann – dafür müssen die Analysen allerdings ausgereift genug sein, dass man sich nicht zu sehr einschränken muss. Statische Analysen sind jedenfalls sehr hilfreich bei der Entwicklung.

    Antworten
  3. Ich denke spätestens wenn man viel Magic wie __call nutzt kann das Tool eh nix mehr machen. Aber es generiert ja wie schon im Artikel beschrieben nur eine Liste, die man per Hand durchgehen muss. Aus diesem Grund ist das auch eher etwas für einen Review aber kein Plugin fürs CI-System.

    Antworten
  4. Eine Untersuchung darüber, nach welchen Kriterien das Tool Code als „tot“ einstuft, wäre interessant gewesen. So aus dem Lesen heraus kann ich mir kaum vorstellen, dass so ein Tool sinnvoll für Software ist, die mit Autoloadern, generischen Klassennamen o.ä. arbeitet.

    > „Aber es generiert ja wie schon im Artikel beschrieben nur eine Liste, die man per Hand durchgehen muss.“

    Und jetzt schätzen wir alle mal, wie oft man sich die Mühe macht, diese Liste durchzugehen und falsch erkannte Scripte aussondert.. 🙂

    Antworten
    • Nunja, wenn für Refactoring Zeit eingeräumt wird, kann man neben CodeSniffer, phpmd etc auch mal eben noch diese Liste durchgehen. Wenn der Arbeitgeber für phpmd keine Zeit zur Verfügung stellt, dann auch nicht um toten Code zu entfernen.

      Am besten ist natürlich, wenn man gar keinen toten Code produziert 🙂

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.