“And I heard a voice in the midst of the four beasts
Revelation
And I looked, and behold a pale horse
And his name that sat on him was death, and hell followed with him”
In vielen Sourcecode Dateien finden sich Abschnitte wieder, die von Softwareentwicklern liebevoll Toter Code genannt werden
Diesen Toten Code gibt es in vielen Variationen. Da gibt es zu einem den Code, der wirklich tot ist. Das sind die auskommentierten ehemalige Methoden und Attribute die keine Verwendung mehr besitzen. Einige Entwickler lassen solche Code-Fragmente stehen, wie trockene Blumen zwischen den vergilbten Seiten ihrer alten Büchern. Vielleicht um sich an irgendwelche alten Episoden im Projekt zu erinnern, findet man diese störende Bruchstücke wild verteilt in den Repositories.
Aber auskommentierter Code ist wenig hilfreich, hat keinen Bezug mehr zum aktuellen Code, stört beim Lesen und bringt Entwickler in den meisten Fällen auf falsche Ideen. Es nur eine Art und Weise mit auskommentierter Code umzugehen. Sobald man ihn entdeckt, muss er umgehen gelöscht werden.
Meist spricht man aber von Toten Code, wenn er tatsächlich noch aktiver Bestandteil der Sourcen ist. Also Programmfragmente, die vom Programmfluß abgeschnitten wurden. Das können Methoden sein, die nicht mehr aufgerufen werden, Bedingte Anweisungen, die einen Fall nie durchlaufen oder Ausnahmebehandlungen die nie zur Anwendung kommen.
if ("test".toUppercae().equals("TESt") {
doNever();
}
In diesem Beispiel wird die Methode doNever() niemals aufgerufen, weil der Vergleich niemals erfolgreich sein kann. Vielleicht ist dies der einzige Aufruf dieser Methode im gesamten Source. Dann werden dutzende, ja vielleicht sogar hunderte oder tausende Zeilen Code nicht gelöscht, obwohl sie niemals verwendet werden.
Obwohl sich der Begriff Toter Code eingebürgert hat, sollte er eigentlich Zombi-Code heißen. Denn er ist nicht tot. Diese vielen Zeilen unnützen Code müssen weiterhin gepflegt werden. Ändern sich beispielsweise die Signaturen von Methoden, die aufgerufen werden, oder werden neue Ausnahmen geworfen, dann müssen diese Änderungen auch im ungenutzen Code eingearbeitet werden.
Häufig ist es auch so, dass den Entwicklern überhaupt nicht bekannt ist, ob der Code verwendet wird. Dann werden Unit- und Integrationstests dazu gepflegt oder manchmal sogar neue Tests ergänzt. Auch das immer wiederkehrende Analysieren des Code durch neue oder vergessliche Kollegen kostet Zeit und Nerven.
Also gilt auch hier der Grundsatz, Zombi-Code muss sofort beseitigt werden. Selbst in dem unwahrscheinlichen Fall, dass dieser Code tatsächlich einmal wieder genutzt werden könnte, ist ein Neuschreiben der Funktionalität immer die bessere Wahl.