Clean Code steht für eine Programmierung mit der Zielsetzung einer nachhaltigen und effizienten Software-Entwicklung (siehe Blogpost Warum die viadee auf Clean Code setzt). In diesem Blogpost greift Christoph Meyer auf die Sprache der alten Griechen zurück, um zu erklären, warum das Naming für Clean Coder:innen eine der wichtigsten Aufgaben ist.
Amphoren, Kannen und Gefäße: Die alten Griechen hatten viele Namen für unterschiedlich geformte Behältnisse für Flüssigkeiten. Die Unterscheidung entstand sicher aus der Notwendigkeit, verschiedene Gefäße wegen ihres unterschiedlichen Zwecks auch unterschiedlich zu benennen. In der Verwendung im Alltag war es dann ein großer Unterschied in der Menge, ob man Wein in einer Pelike oder Kylix bekam. Nicht nur preislich, sondern auch in der Menge an Alkohol.
Bild: Schon Sokrates und die alten Griechen haben lange über die richtigen Namensbezeichnungen nachgedacht.
Wenn wir Software bauen, sollten wir die passenden Namen ebenfalls mit Bedacht wählen und uns länger Gedanken machen, welches der richtige Name für die von uns erschaffenen Programmkonstrukte ist. Es existiert eine Verbindung zwischen der realen, physischen Welt um uns herum, die wir sehen und anfassen können, und der virtuellen Welt, die wir durch Software erschaffen. Diese beiden Welten sind miteinander verbunden und beeinflussen sich gegenseitig: so finden Namen aus der physischen Welt ihren Eingang in die digitale Welt und andersherum. Naming ist damit ein wichtiger Baustein von Clean Code.
Clean Code als Ordnungsrahmen für die Erhöhung der Softwarequalität lässt sich mit der Böhm-Kurve gut darstellen. Sie stellt einen exponentiellen Verlauf der Wartungskosten im Zeitablauf (ohne Clean Code) einem möglichen sub-exponentiellen Verlauf bei Nutzung von Clean Code Prinzipien und Praktiken gegenüber. Fakt ist, dass Quellcode mehr als zehn Mal so oft gelesen wird, wie er geschrieben wird. Daher erhöht eine Überarbeitung des Codes mit besseren Namen das Verständnis für den Code und spart in Zukunft viel Zeit bei Problemanalysen, Erweiterungen und Debugging ein. Als Hilfe dafür gibt es ein paar Leitlinien, um gute Namen zu finden.
Acht Clean Code-Prinzipien für das Naming
-
Zweckbeschreibende Namen wählen
Es wäre schön, wenn der Name selbsterklärend wäre und sich dabei auf das Wesentliche konzentriert. Im Java-Umfeld sieht man leider häufig Hässlichkeiten wie „akzeptiereNeukundenAnlageUndReicheDieDatenWeiterOhnePruefung()“. Wenn möglich, sollte man auf die Bindewörter „und“ und „oder“ in Bezeichnern verzichten und maximal 3-4 Hauptwörter verwenden.
-
Fehlinformationen vermeiden
Leider sieht man in der Praxis immer wieder, dass Methoden- oder Variablennamen schlicht falsch sind, oft weil sie mit Copy + Paste aus anderen Kontexten gerissen und anderswo eingefügt wurden. Ein „speichereDaten()“ sollte das auch tun und nicht nur die Prüfungen vor dem Speichern enthalten und dann delegieren. Namen sollten auch einigermaßen vollständig sein, ein „toByteArray(HochgeladeneDatei)“ sollte nicht heimlich die Links entfernen, falls es ein PDF ist.
-
Unterschiede deutlich machen
Bei ähnlichen Methoden oder Variablen sollte man die Unterschiede betonen und nicht die Gleichheit ausnutzen. Postfixe wie „A, B, C“ oder „1, 2, 3, …“ sind für das Verständnis schlecht. Statt „berechnungswertA“ und „berechnungswertB“ sollten Namen gewählt werden, die kennzeichnen, wo sich die Berechnungswerte unterscheiden.
Ähnliche Konstrukte sollten jedoch auch ähnlich benannt sein: „starteRaumschiff“ und „spaceshuttleLaunch“ wären hier Negativbeispiele. -
Aussprechbare Namen verwenden
Man sollte sich klar machen: Menschen sprechen Namen aus! Wer Konstrukte anlegt, die sich lächerlich anhören oder die unaussprechlich sind, fördert höchstens die Lachmuskeln der Kollegen. Auch auf humorige Namen wie beispielsweise „bool dozer“ oder „long timeago“ sollte man verzichten.
-
Suchbar sollten sie sein
Code wird nicht nur häufig gelesen, er wird auch oft durchsucht. Es hilft dafür wenig, wenn Namen zu häufig vorkommen oder mehrfach in verschiedenen Kontexten verwendet werden. Eine Methode „getData“ in einer großen Codebasis zu suchen, kann sich schnell als unlösbare Aufgabe herausstellen.
-
„Ungarisch"
Technische Informationen haben im Namen nichts verloren (auch als „ungarische Notation“ bekannt). Beispiel sind hier „fMyCounter“ (hier steht das „f“ als Präfix für „field“) oder „booleanIstKundeAngemeldet“. In weniger streng getypten Sprachen können solche Informationen wichtig sein, in Java (oder anderen streng getypten Sprachen) sind sie in der Regel überflüssiger „Clutter“, der das Lesen stört. Die Informationen werden in der Regel mithilfe der IDE dargestellt. Auch auf Präfixe in Namen sollte man generell verzichten.
-
Guck mal, wer da spricht
Naming ist umso wichtiger, umso weitreichender der Quellcode verwendet wird, gerade bei Schnittstellen zu anderen Systemen. Insbesondere bei APIs, in Interfaces, bei abstrakten Klassen, bei Domain Objects und bei der Strukturierung der Anwendung in den Packages und Verzeichnissen gibt unsere Namenswahl maßgeblich die Implementierung von (Fremd-)Code vor, der unsere Namen weiter nutzen wird. Wenn wir nicht wollen, dass die Nutzer unserer Schnittstellen in ihrem Code unverständliche Konstrukte bauen, sollten wir erst einmal selbst klare und verständliche Namen verwenden.
Fazit Naming im Clean Code
Namen als virtuelle Konstrukte in Programmcode sind sehr langlebig und daher als wichtiger Baustein von Softwarequalität zu berücksichtigen, doch sind sie eben nur ein Baustein unter vielen anderen.
Wie geht Clean Code? Unser Praxisseminar Clean Code Kompakt
Wir vermitteln unser Clean Code-Wissen mit vielen weiteren Praxistipps und konkreten Übungen in unserem Seminar Clean Code Kompakt – Praktiken und Prinzipien für gute Software. In diesem lernen die Teilnehmenden die Prinzipien und Praktiken des Clean Code Development anhand von praktischen Beispielen kennen und profitieren dabei von den Erfahrungen unserer Trainer und Trainerinnen. Sie nehmen Ideen und Ansätze mit, um ihre alltägliche Arbeit effizient zu organisieren, bekannte Probleme dauerhaft zu lösen und Wissen im Team nachhaltig zu teilen.
zurück zur Blogübersicht