Nachdem wir die zu erfüllenden Anforderungen kennen, müssen wir nun Merkmale finden in denen sich die Anforderungen widerspiegeln. Merkmale, die es erlauben den Grad zu messen in dem die Anforderungen erfüllt sind. Es giebt eine unglaubliche Menge von Vorschlägen für Eigenschaften, Merkmalen oder Qualitäten die Code haben sollte oder nicht haben dürfen soll um als „guter Code“ zu gelten. Man kann diese Merkmale auch — zumindest teilweise — den genannten Anforderungen zuordnen.

Und an dieser Stelle fangen die Probleme an. Die Menge der Regeln ist riesig und die der diskutierten Auslegungen unüberschaubar. Tatsächlich ist die Vorstellung von Code-Qualität nicht absolut. Sie ist abhängig von Zeit, Kultur, verwendeter Technologie, Fachlichkeit und vielen anderen Faktoren. Die wenigen allgemeingültigen Regeln sind dermaßen abstrakt formuliert, daß sie kaum unmittelbar anwendbar sind. Und sobald man versucht ihre Anwendung zu konkretisieren, starten die Diskussionen.

Jedes Team und jede Organisation, die versucht die Code-Qualität zu verbessern muß damit beginnen ein gemeinsames Verständnis für die Qualität zu entwickeln. Ohne ein solches Verständnis findet man keine Einigung und Regeln werden entweder gar nicht erfüllt oder sie werden nur um der Erfüllung willen erfüllt. Gesetzte Regeln müssen verstanden und immer wieder auf ihre Sinnhaftigkeit hinterfragt werden. Das ist aufwändig und erfordert Engagement — wer ist bereit dafür Energei aufzubringen?

In den alten Tagen war es üblich, Code-Qualität am Verhältnis von Kommentar- zu Code-Zeilen zu messen. Je größer das Verhältnis desto besser. In der Folge sind viele Entwickler dazu übergegangen, den Code mit leeren Kommentar-Zeilen aufzufüllen. Die Metrik wird erfüllt, aber was hat das mit Qualität zu tun?

Metriken führen nicht zu Code von besserer Qualität,
sondern zu Code der die Metriken erfüllt.

Moderne Metriken scheinen besser geeignet zu sein. Man zählt die Methoden der Klasse, die Zeilen von Methoden und Funktionen, man mißt die Abdeckung des Codes mit Unit-Tests und die Kohärenz in Modulen. Aber was ändert das an der Einstellung des Entwicklers? Wer schnell viel Code generieren will (oder muß), der findet Wege die Metriken zu erfüllen ohne dabei die Code-Qualität ändern zu müssen.

Qualität ist die Einstellung des Entwicklers,
die vom Code reflektiert wird.

Macht das Regeln — und die Metriken die sie messen — überflüssig oder unsinnig? Nein. Der qualitätsorientierte Entwickler sollte alle Mittel nutzen — und zumindest ernsthaft erproben — um die Qualität zu verbessern. Die vielleicht beste Formulierung diese Gedankens stammt von Michael Feathers:

Clean Code always looks
like it was written by someone who cares.

Michael Feathers

Die Kommentar-Metrik zeigt aber noch ein anderes Problem. Keine Metrik kann messen wie hoch der Bezug ist den der Code zu seiner Semantik hat. Man könnte diese Eigenschaft als „Angemessenheit“ bezeichnen. Betrachten wir diese Zeile:

int x = a + b;

Sie ist zu umfangarm um irgendeine Aussage über ihre Qualität zu machen. Sobald wir aber die Variablen umbenennen und schreiben:

int differenz = soll + ist;

macht die Zeile überhaupt keinen Sinn mehr. Sie widerspricht sich plötzlich selbst. Die zusätzliche semantische Information die durch die Bezeichner transportiert wird ist für den Compiler schlichtweg unsichtbar. Ebenso wie die Information die gar nicht im Code enthalten ist, weil sie nur im Fachkonzept existiert.

Was können wir also über die meßbaren Merkmale von Code-Qualität sagen? Sobald wir festgelegt haben, welchen Regeln wir folgen möchten, können wir dazu Merkmale festlegen an denen wir die Code-Qualität messen können. Sobald sich unser Verständnis der Qualität ändert müssen wir die Merkmale anpassen. Ausreichend sind solche Merkmale aber nicht, die Übereinstimmung des Codes mit seiner Bedeutung können sie nicht erfassen.