Grundlagen der Programmierung: Codemetriken

Toter Code (LoDC)

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Code der nicht genutzt wird, gilt als tot. Hier erklärt Hendrik Lösch, warum er dennoch eine Gefahr darstellt und wieso es so schwer ist, ihn zu finden.
05:24

Transkript

Eine Einschätzung für die Qualität der Codebasis gibt vor allem auch der Anteil des toten Codes. Es liegt nicht unbedingt auf der Hand, da toter Code schwer zu erkennen ist Widmen wir uns also dem toten Code beziehungsweise den "Lines of Dead Code". Grundsätzlich ist es immer so, dass in unserem Code Abhängigkeiten bestehen. Also von hier A nach B bis weithin zu X. Nun kann es sein, dass dies Methodenaufrufe sind. Also die Klasse A ruft beispielsweise Methoden von Klasse B auf. Wenn nun dieser Methodenaufruf nicht mehr vorhanden ist, dann wird B in unserer Applikation nicht mehr verwendet. Da beim Löschen einer solchen Referenz aber nicht der gesamte Code von B gelöscht wird, ändert sich am Gesamtvolumen unserer Codebasis nichts, der Code ist noch immer vorhanden und muss gepflegt werden. Aus diesem Grund gibt es diverse Analyseverfahren, die probieren, zu ermitteln, wie viele Prozent unserer Codebasis tot sind. Wie viele wir im Grunde löschen könnten, ohne dass es irgendeine Veränderung am Verhalten unseres Quellcodes gibt. Viele Entwicklungsumgebungen haben heutzutage bereits Analysen eingebaut, die uns bereits im Editor anzeigen, ob Code tot ist. So wird dann beispielsweise die Methode oder der Variablenname ausgeblendet. Dies zeigt uns an, du verwendest hier etwas nicht. Weil es kann ja auch darauf zurückzuführen sein, dass wir zwar den Code verwenden wollten, aber versehentlich beim Schreiben eine ganz ähnliche Methode mit gleichen Namen aufgerufen haben. Es funktioniert leider nicht immer ganz gut. Denn das Problem beim toten Code ist natürlich, diesen überhaupt erst einmal zu erkennen. Denn toter Code bedeutet ja, dass keine Referenz auf ihn besteht. Wenn wir also nur prüfen, ob A eine Referenz auf B hat, dann wird B natürlich als toter Code erkannt. X aber nicht. Und das kann in vielen Situationen passieren beziehungsweise kann die entsprechenden Analyseverfahren ziemlich verwirren. Hier im Beispiel. Die abgeleitete Methode "InitializeShell" wird mit einer Referenz gekennzeichnet. Das ist interessant, weil "InitializeShell" an dieser Stelle nur einmal aufgerufen wird, und zwar bei "base.InitializeShell". Die Methode selbst ruft ihre Basisklasse auf und das verwirrt das Analyseverfahren. Dem gegenüber wird in der gleichen Klasse die Methode "CreateShell" als nicht referenziert angezeigt. Das ist auch korrekt, weil innerhalb unseres Quellcodes an dieser Stelle die Methode gar nicht aufgerufen wurde. Dass "CreateShell" vom umgebenen Framework genutzt wird, um beim Bootstrapping meiner Anwendung das Hauptfenster zu erstellen, das können die Analyseverfahren nicht wissen, da sie den fremden Quellcode nicht analysieren. Während es sich also im oberen Fall durchaus um toten Code handeln kann, handelt es sich im unteren Fall definitiv nicht um toten Code, obwohl meine Analyseverfahren dies geglaubt haben. Ein weiterer Punkt, der schnell zu Verwirrung führen kann, ist, dass Methoden auch von Testmethoden referenziert werden. Durch die Referenzierung aus der Testmethode heraus, kann nicht gesehen werden, ob diese Methode überhaupt noch verwendet wird. Dabei muss ich aber sagen, dass getesteter, toter Code zumindest noch den Vorteil hat, dass er getestet wird. An den Auswirkungen, die es auf die Wartung der Applikation hat, auch weil wir natürlich zusätzliche Testfälle haben, die wir pflegen müssen und so weiter und so fort, hat es natürlich keine Auswirkungen. Also selbst getesteter, toter Code ist immer noch toter Code und daher ebenfalls schlecht, er ist nur umso schwerer zu erkennen, weil es auf ihn ja entsprechende Referenzen gibt. Viele dieser Dinge werden von guten Analysetools auch erkannt, indem sie den Abhängigkeitsgraph analysieren, und damit natürlich auch Rückschlüsse darauf ziehen können, inwiefern Transitivität jetzt Einfluss auf toten Code hat, aber was erst zur Laufzeit festgestellt werden kann, das wird eben erst zur Laufzeit festgestellt. Hier in diesem Beispiel ist es so, wenn beispielsweise zur Laufzeit immer eine Exception geworfen wird, dann wird niemals der "content" mit "myString" initialisiert. An dieser Stelle entsteht toter Code also zur Laufzeit, und wirkt dort verwirrend. Weiterhin toter Code ist, Code, der einfach nur auskommentiert wurde. das Gute ist, diesen können wir verhältnismäßig einfach erkennen, da er A) eindeutig gekennzeichnet ist und B) uns auch bei der Analyse der Gesamtanzahl von Kommentaren auf die Füße fällt. So etwas sieht man beispielsweise, wenn Personen Angst haben, Code zu verlieren, weil Sie der Quellcodeverwaltung nicht vertrauen oder Ähnliches. In jedem Fall ist es so, dass wir probieren sollten möglichst keinen toten Code in unserer Anwendung zu haben. Insofern Sie genügend automatisierte Tests haben, können Sie sich durchaus auch mal zutrauen, Quellcode zu löschen, und wenn Sie Ihren Quellcode eh schon auskommentieren, dann können Sie ihn auch gleich löschen. Den Rest besorgt die Quellcodeverwaltung.

Grundlagen der Programmierung: Codemetriken

Lernen Sie Methoden, Prinzipien und Werkzeuge kennen, mit deren Hilfe Sie die Qualität Ihrer Software dauerhaft sicherstellen können.

1 Std. 43 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!