Clean Code – Aussagekräftige Namen
Was einen guten Namen ausmacht, beschreibt Robert „Uncle Bob“ Martin im zweiten Kapitel seines Buches „Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code“. Ich möchte euch in diesem Beitrag die aus meiner Sicht wichtigsten Punkte zusammenfassen. Im Beitrag „Clean Code – nicht nur richtig, sondern gut entwickeln“ habe ich bereits einen Überblick über das Buch gegeben – nach wie vor eine riesen Leseempfehlung für jeden Entwickler.
Zweckbeschreibende Namen verwenden
Das Wichtigste als Erstes: Der Name einer Variable, Funktion oder Klasse sollte den Zweck verständlich beschreiben. Das klingt erstmal banal, ist aber sehr wichtig. Wenn ein Name einen Kommentar benötigt, ist er nicht gut genug. Ein guter Name beantwortet diese wichtigen Fragen von alleine:
- Warum existiert das Element?
- Was tut es?
- Wie wird es benutzt?
Der VariablenName d sagt nichts aus. Die Namen durationInDays, creationDate oder document sind da schon viel besser. Im Kontext der Klasse oder der Funktion kann man an diesen Namen sofort erkennen, um was es geht.
Ein schönes Beispiel aus dem Buch ist dieser Code-Abschnitt:
function getThem(): int[][] {
const list1: int[][] = [];
for (x of theList) {
if (x[0] == 4) {
list1.add(x);
}
}
return list1;
}
function getFlaggedCells(): Cell[] {
const flaggedCells: Cell[] = [];
for (cell of gameBoard) {
if (cell[STATUS] == Status.FLAGGED) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
Der Code auf der rechten Seiten ist identisch zu dem auf der linken Seite. Man versteht aber viel schneller, was gemeint ist. Wenn man dann auch noch weiß, dass wir gerade Minesweeper entwickeln, ist sofort alles klar. Noch besser wird es natürlich, wenn der Typ Cell eine eigene Klasse wird und wir die Bedingung als cell.isFlagged() schreiben können, aber dazu in einem späteren Beitrag mehr.
Abkürzungen, Gespräche und Nachdenken
Eng damit zusammen hängt das offensichtliche Bedürfnis von vielen Entwicklern, möglichst kurze Variablennamen zu finden. Die haben aber mehrere Nachteile.
Jeder Entwickler, der am Projekt arbeitet, muss die Abkürzungen kennen. Als ich in ein Projekt eingestiegen bin und überall von qry, rq, ctx, prj, evt die Rede war, hatte ich keine Ahnung, was hier los ist. Erst nachdem mir ein Kollege die Bedeutungen aller Abkürzungen erklärt hatte, klärte sich der Nebel – Zeit, die wir beide uns hätten sparen können, wäre gleich von query, request, requestContext, projekt und event die Rede gewesen.
Aber auch Entwickler, die das Projekt gut kennen, müssen jedes mal gedanklich das Mapping zwischen Abkürzung und tatsächlicher Bedeutung vornehmen. Das ist vor allem ein Problem bei Variablennamen mit nur einem Buchstaben. Natürlich kann der Zähler einer Schleife i oder j oder k heißen (aber niemals l!). Der Scope dieser Variable ist aber auch sehr begrenzt und i ist als Bezeichner für Loop Counter quasi schon eine Tradition. In den meisten anderen Kontexten ist ein Name mit nur einem Buchstaben jedoch eine schlechte Wahl. Er ist nur ein Platzhalter, den der Leser gedanklich dem eigentlichen Konzept zuordnen muss.
Und hier muss ich einfach mal einen längeren Abschnitt aus dem Buch von Uncle Bob zitieren:
Im Allgemeinen sind Programmierer ziemlich clevere Menschen. Clevere Menschen stellen ihre Intelligenz manchmal gerne zur Schau, indem sie ihre geistigen Jonglierfähigkeiten unter Beweis stellen. Denn wenn man sich zuverlässig merken kann, dass r die kleingeschriebene Version der URL ist, bei der Host und Schema entfernt wurden, dann muss man eindeutig sehr clever sein.
Ein Unterschied zwischen einem cleveren Programmierer und einem professionellen Programmierer besteht darin, dass der Profi weiß, dass Klarheit das Wichtigste ist. Profis setzen ihre Fähigkeiten zum Guten ein und schreiben Code, den andere verstehen können.
(Robert C. Martin, „Clean Code“)
Dazu kommt, dass man Abkürzungen oft nicht sinnvoll aussprechen kann. Das Beispiel aus dem Buch ist genymdhms (generation date, year, month, day, hour, minute, and second); ausgesprochen also „gen why emm dee aich emm ess“ oder „gen-yah-muddahims“. Stellt euch mal ein Review oder Pair Programming mit einem Kollegen vor – klingt in meinen Ohren nicht wirklich clever. Also besser einen Namen wählen, der von allen ausgesprochen werden kann: generationDate oder generationTimestamp zum Beispiel und wenn unbedingt nötig auch generationIsoDate, aber da hat die nächste Regel was dagegen.
Die Faustregeln für Namen
Uncle Bob formuliert 3 Faustregeln für bessere Namen:
- Je geringer der Scope einer Variable, desto kürzer kann der Name sein.
- Je häufiger eine Funktion verwendet wird, desto generischer kann ihr Name sein.
- Wird eine Funktion nur einmal (oder sehr selten) aufgerufen, kann sie einen sehr langen und konkreten Namen haben.
Fazit
Ich kann in diesem Beitrag natürlich nur auf die essenziellen Grundlagen eingehen. Uncle Bob hat zu dem Thema aber noch mehr zu sagen und erklärt noch weitere Schwierigkeiten. Besonders interessant war für mich dabei der Aspekt, dass man keine unterschiedlichen Namen für dasselbe Konzept verwenden sollte. Soweit logisch. Problem dabei ist nur, dass es schnell passieren kann, dass man dann denselben Namen für ähnliche, aber semantisch unterschiedliche Konzepte verwendet. Zudem zeigt Uncle Bob, warum er Interfaces nicht mit einem Prefix oder Postfix versieht, sondern lieber die Implementierung anders benennt.
Das Wählen eines guten Names kann schwierig sein und benötigt ein bisschen Zeit. Aber auf Dauer sparen gute Namen wesentlich mehr Zeit ein. Es lohnt sich also, sich die Zeit zu nehmen, um gute Namen zu finden. Man sollte sich nicht scheuen, einen Namen zu ändern, wenn man einen besseren findet. Das Schwierigste beim Finden eines guten Namens ist aber, dass man gute beschreibende Fähigkeiten braucht. Es ist also eher eine Übungssache als eine Technik- oder Business-Frage.
Wer also tiefer in das Thema einsteigen möchte, mehr Beispiele und noch weitere spannende Aspekte zu guten Namen verstehen will, sollte sich das Buch besorgen. Mir hat das erneute Lesen des Kapitels wieder eine Menge Spaß gemacht und auch nach mehrmaligem Lesen lerne ich noch Neues dazu und merke, das auch ich noch Verbesserungspotential habe – nobody is perfect.
Tipp
Starte jetzt dein Projekt mit WordPress − dem beliebtesten CMS der Welt! Die Geeks in unserem Support stehen dir 24 Stunden an 365 Tagen im Jahr zur Seite. Wir halten dir den Rücken frei. Du kannst dich voll und ganz deinem Projekt widmen.
Kommentar hinzufügen