Clean Code – Teil 1: Naming Smells

Naming is hard …

In den Neunzigern sagte Phil Karlton:

„There are only two hard things in Computer Science: cache invalidation and naming things.“

Über zwanzig Jahre später gilt scheinbar immer noch: es ist schwierig, programmiersprachliche Konstrukte gut zu benennen. Und das, obwohl schlechte Namen sofort auffallen: nämlich dann, wenn Code schwer zu verstehen ist.

Allerdings erkennt vielleicht nicht jeder sofort, woran das im Einzelnen liegt. Ein paar klassische Beispiele für (fast) offensichtlich schlechte Namen sind:

• unlesbare Abkürzungen wie „AcctMgr“ – spart Zeit beim Tippen, die man hinterher beim Lesen mehrfach aufbringen muss.
• unsinnige Platzhalter wie „foo“, „doStuff“, die anscheinend nicht aufgeräumt worden sind
• glatte Lügen, wie eine „get“-Methode, die nichts zurückgibt
• fehlerhafter Plural/Singular, z.B. „image“ statt „images“ für eine Liste von Objekten vom Typ „Image“

Namen, die etwas Falsches bezeichnen, entstehen oft durch eine Änderung an der Code-Struktur oder -Logik, ohne dass die Namen mit angepasst werden. Solche Fehler sind relativ leicht zu erkennen, und zu beheben.

Trickreicher sind Namen, die zwar stimmen, aber zu allgemein sind. Die Klassiker sind „…Data“, „…Manager“, „…Object“, „process…“ – man könnte sie fast genauso gut „Thing1″, Thing2“, … nennen. Wenn es schwer fällt, einem Konstrukt einen konkreten Namen zu geben, dann ist das oft ein Hinweis darauf, dass mit diesem Konstrukt etwas nicht stimmt. Oder man hat sich nicht genug Gedanken darüber gemacht…

… or is it?

Gute Namen zu finden ist nicht immer einfach, aber auch keine Zauberei. Man muss ein wenig Zeit investieren und es bedarf auch etwas Übung. Der erste Schritt ist die Einsicht, dass es sich lohnt. Die kommt schnell, sobald man sich schwer tut, Code zu verstehen, den man vor einer Weile selbst geschrieben hat. 🙂

Der zweite Schritt ist es, „Naming Smells“ (oder „antipatterns“) wie in den Beispielen oben, als solche zu erkennen und zu beheben. Peter Hilton hat in seinem Blog eine Reihe von Naming Smells aufgelistet. Und hier ist eine weitere Liste, die zugleich eine Zusammenfassung von wissenschaftlichen Arbeiten zu diesem Thema ist. Davon ein kleiner Auszug:

• Exccessive Words: „floatToRawIntBits()“
• External Underscores: „_foo_“
• Naming Convention Anomaly: „FOO_bar“
• Name suggests Boolean, but type does not: e.g. attribute „isReached“ of type „int[]“

Bei der Gelegenheit empfiehlt es sich, auch andere „Code Smells“ zu rekapitulieren, wie zum Beispiel:

• Duplizierter Code, und schlimmer: duplizierte Logik mit minimal unterschiedlichem Code
• „God Object“
• „Primitive Obsession“: der Einsatz von allgemeinen primitiven Datentypen (int, bool, string, ..) anstatt von domänenspezifischen Typen (Money, Date, Address, Angle, …)

Peter Hilton gibt hier auch ein paar sehr grundlegende Tipps, was man tun kann, um bessere Namen zu vergeben:
Einerseits empfiehlt er, das Sprachgefühl für Englisch zu verbessern (durch lesen, schreiben, Scrabble spielen).
Andererseits sollte man immer die Fachdomäne, für die eine bestimmte Software geschrieben wird, möglichst gut kennen und verstehen. Dann kann man das spezifische Vokabular aus der Fachdomäne im Programmcode verwenden, und muss keine neuen Namen erfinden. Dies wiederum führt direkt zum Thema Domain Driven Design, aber das ist eine eigene Geschichte… Deshalb wird es dazu bald einen eigenen Blog-Artikel geben.

Ausblick: Anleitung zum Verbessern von Namen in Legacy Code

Neben den oben genannten, eher grundsätzlichen Tipps gibt es zu dem Thema auch eine hervorragende Artikelserie von Arlo Belshee „Good naming is a process, not a single step“ . Darin liegt der Fokus auf Benamung im Kontext von Legacy Code und Refactoring. Da diese Serie sehr methodisch aber auch sehr ausführlich ist, wird sich der nächste Blog-Eintrag in dieser Reihe damit beschäftigen.

Weitere Weblinks zum Thema:

1. Episode 278 im Software Engineering Radio: Interview von Felienne mit Peter Hilton über Naming: http://www.se-radio.net/2016/12/se-radio-episode-278-peter-hilton-on-naming/
2. Zum Zitat von Phil Karlton: https://www.martinfowler.com/bliki/TwoHardThings.html