Die Gefahren des toten Codes

Judith Lungstraß

Stellt euch folgendes Szenario vor: Ihr wollt eine Implementierung durch eine andere ersetzen, seid euch aber noch nicht hundertprozentig sicher, ob der neue Weg denn auch tatsächlich funktioniert. Was tut ihr? Genau, ihr schreibt die Implementierung neu und kommentiert den Code aus, der vorher ihre Aufgabe erfüllte. Sollte irgendetwas schief gehen, kann man ja immer noch die Schrägstriche, Klammern und Sternchen entfernen und alles ist wieder beim Alten. Ein sicherer Hinterausgang sozusagen.

Situationen wie diese kennt wohl jeder Entwickler – und das ist auch nicht schlimm. Bedenklich wird es erst dann, wenn dieser auskommentierte Code über lange Zeit, ja vielleicht sogar über Jahre hinweg, ungenutzt stehen bleibt. Der ursprüngliche Entwickler bemerkt die Gefahr des toten Codes nicht – wie auch, schließlich erfüllt der auskommentierte Code ja keine direkte Funktion mehr.

Solch eine Unbeschwertheit kritisiert nun der erfahrene belgische Entwickler Martin Van Aken in seinem Blogbeitrag „Dead code is rotting your codebase.“ Ihm zufolge hat auskommentierter Code nämlich sehr wohl eine Funktion: Sie verwirrt den Kollegen, den Chef und eventuell auch den Entwickler selbst, wenn er sich seinen Code nach einem gewissen Zeitraum noch einmal ansieht.

Weshalb nur wurde der Code auskommentiert und nicht gelöscht?, ist da eine naheliegende Frage. Bevor man dann etwas Falsches tut, lässt man die auskommentierten Stellen also stehen – und trägt damit zur allmählichen „Verrottung“ der Codebasis bei.

Und dabei sollten Kommentare im Code doch den Dritten im Bunde zwischen Entwickler und Anwendung an der Hand nehmen, ihn führen und zum Verständnis des Programmiersprachen-Gewirrs beitragen.

Die Maschine braucht solch einen Leitfaden nicht. Ist der Code syntaktisch korrekt, versteht sie ihn, vollkommen egal wie kryptisch und schwer er zu lesen ist. Wenn wir also darüber nachdenken, wie wir unseren Code besser machen können, strukturierter, sauberer und einfacher zu verstehen, sollten wir vor allem den Menschen als potentiellen Adressaten im Hinterkopf haben. Und dieser Mensch stört sich eben an überflüssigen Elementen, die zwar nicht (mehr) benötigt werden, aber trotzdem noch da stehen und seine Aufmerksamkeit in Anspruch nehmen.

Bis zum Refactoring hat auskommentierter Code eine Daseinsberechtigung. In diesem Prozess sollte man ihn allerdings nach und nach löschen, sodass er spätestens dann weg ist, wenn eine andere Person die eigene Arbeit zu Gesicht bekommt!

Beim nächsten Auskommentieren sollte man sich also durchaus einmal Gedanken machen, ob der unmittelbare praktische Nutzen die Gefahren der „allmählich verrottenden Codebasis“ rechtfertigen. Wozu gibt es denn schließlich Quellcodeverwaltungssysteme – Git, SVN, CVS, Mercurial ….

Geschrieben von
Judith Lungstraß
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.