Code Smells: Wenn Code anfängt zu stinken

Jeder, der schon eine Weile programmiert, wird die Situation kennen: Man liest Code (entweder fremden oder eigenen) und es läuft einem kalt den Rücken runter, die Zehnägel stellen sich auf und man will nur noch wegsehen. Wer das noch nie erlebt hat, sollte einfach mal seine ersten Programmierversuche wieder herauskramen.

Mancher Code scheint einfach zum Himmel zu stinken. Treffenderweise nennt man so etwas „Code Smell“. Letztens habe ich bei Nick Hodges von einem Stackoverflow-Thread über solche Code Smells gelesen.

Ich dachte mir, das passt wunderbar zu der an den Delphi-Tagen angekündigten (und leider immer noch nicht wirklich begonnenen) Artikelserie zu den Prinzipien der (objektorientierten) Softwareentwicklung. Wahrscheinlich werde ich zu jedem diskutierten Prinzip – wenn möglich – ein paar Code-Smells als abschreckendes Gegenbeispiel benennen. Hier aber erstmal ein paar allgemeine Gedanken zu Code Smells:

Code Smells sind meistens recht schnell zu finden. Sie stinken ganz offensichtlich. Eine 200-Zeilen-Methode zum Beispiel. Man sieht ganz eindeutig, dass diese höchstwahrscheinlich unnötig lang ist. Oder eine Methode mit 15 Parametern. Eine solche ist ebenfalls leicht zu bemerken.

Wenn man gerade anfängt zu programmieren, riecht man diese Code Smells oft nicht. Man muss dafür erst ein gewisses Gefühl entwickeln. Manche Code Smells bemerkt man recht früh, für andere muss man schon recht viel programmiert haben. Wenn man diese Nase aber erstmal entwickelt hat, riecht man die Code Smells überall.

Wie ich schon in meinem Vortrag zu OO erwähnt habe, sehe ich Softwareentwicklung als das ständige Ausbalancieren von Daumenregeln. Man hat verschiedene Prinzipien, die sich meist irgendwie widersprechen („KISS: Keep it Simple, Stupid“ vs. „Eine generische Lösung ist besser als eine spezielle“) und sucht einen für das konkrete Problem passenden Mittelweg.

Patterns sind dabei quasi häufig verwendete Musterlösungen für bestimmte Problemstellungen, die mit solchen widerstreitenden Kräften zusammenhängen. Zu den meisten Patterns lassen sich wohl die ausbalancierten Kräfte benennen, auch, wenn das vermutlich nicht immer ganz einfach und nicht immer eindeutig ist.

Auf der anderen Seite gibt es die so genannten Anti-Patterns, also häufig anzutreffende schlechte Lösungen für ein Problem. Und Code-Smalls könnte man als Anti-Pattern auf Code-Ebene betrachten (Patterns auf Code-Ebene nennen sich Idiome). Der Übergang von Code-Smell zu Anti-Design-Pattern ist dabei fließend (wie der Übergang zwischen Idiom und Design-Pattern auch fließend ist).

So wie man zu Patterns die ausbalancierten Kräfte benennen kann, kann man bei Anti-Patterns und so eben auch bei Code-Smells die Prinzipien, also die Daumenregeln, benennen, gegen die sie verstoßen.

Es geht immer darum, den richtigen Mittelweg zu finden und so ist ein Code Smell natürlich noch kein Fehler im engeren Sinne. Ein Code Smell weist nur darauf hin „Guck dir das mal genauer an, wahrscheinlich ist hier was faul“. Für ein konkretes Problem kann auch das vollkommene Ignorieren eines Prinzips (und damit verbunden das Akzeptieren des Code Smells) ein passender „Mittelweg“ sein. Es kommt eben auf das konkrete Problem an. Zudem kann man natürlich bei manchen Code Smells geteilter Meinung darüber sein, ob sie wirklich solche sind und in welchen Fällen.

Ich finde Softwareentwicklungs-Prinzipien, Patterns und Anti-Patterns wichtig und ich denke, ich habe, seit ich mich damit beschäftige, einiges bezüglich Softwareentwicklung gelernt. Es lohnt sich, diese genauer zu betrachten und so steht das immer wieder auf meiner ToDo-Liste.

Wo lassen sich nun Code-Smells betrachten (außer im eigenen Code)? Martin Fowler nutzt den Begriff Code Smell um damit Möglichkeiten für Refactoring aufzuzeigen. In der Wikipedia gibt es eine Auflistung von Fowlers Code Smells.

Es gibt aber deutlich mehr Code Smells. In Ward’s Wiki gibt es dazu eine Liste und sehr empfehlenswert ist auch der erwähnte Stackoverflow-Thread.

Ein Kommentar


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert