# Aussagekräftige Namen ## Einführung Einer der wichtigsten Teile des Clean Codes ist die Namensgebung. Eine gute Wahl der Namen kann einen unleserlichen, extrem komplizierten Code in eine angenehme Geschichte verwandeln. In diesem Teil der Reihe möchte ich darauf eingehen, wie gute Namen gewählt werden, wie schlechte Namen vermieden werden und was zu beachten ist. ## Gute Namen wählen ### Beschreibende Namen Alle Namen sollten möglichst zutreffend zusammenfassen, was der Zweck einer Sache ist. Es ist beispielsweise schwierig herauszufinden wofür das *i* in `int i = 0;` stehen könnte. Trifft man eine solche Variable an, kann es lange Zeit dauern, bis man aus dem Kontext herauslesen kann, wofür sie steht. Ein Name sollte also möglichst viele Informationen enthalten. Ein guter Messwert hierfür sind die W-Fragen: 1. Warum existiert es? 2. Was tut es? 3. Wie benutzt man es? Angenommen, die Variable *i* wurde benutzt um zu Zählen wie viele Noten genügend sind: ```CSharp public int Count(int[] list1) { int i = 0; foreach (int j in list1) { if (j >= 4) { i++; } } return i; } ``` Dieser Code ist noch relativ einfach zu verstehen, da er sehr klein ist. Was ist der Sinn dieser Funktion? Was ist *list1*? Wofür verwendet man *i* und *j*? Eine bessere Namensgebung wäre: ```CSharp public int CountSatisfactoryGrades(int[] grades) { int satisfactoryGrades = 0; foreach (int grade in grades) { if (grade >= _satisfactoryGrade) { satisfactoryGrades++; } } return satisfactoryGrades; } ``` ### Nur die Wahrheit Die Namen sollten detailliert sein. Man muss jedoch beachten, dass man keine Fehlinformationen verbreitet. Wörter die bereits eine Bedeutung haben wie *List* sollten nur verwendet werden, wenn sie zutreffend sind. Ein *Dictionary* sollte also auf keinen Fall *List* benannt werden, auch wenn es im Kontext passender scheint. ### Klare Unterscheidung Hat man viele Elemente bei denen ähnliche Namen verwendet werden können sollte der Unterschied deutlich gemacht werden. Hat man beispielsweise folgende Funktionen: ```CSharp GetProfile(); GetProfiles(); GetProfileDetails(); ``` Hier ist es schwierig herauszulesen worin sich die Funktionen unterscheiden. Angenommen, `GetProfile()` gibt ein Objekt `Profile` zurück und `GetProfileDetails()` ist eine Funktion um die Details in der Konsole auszugeben, dann sollte dies besser in den Namen wiedergegeben werden. ### Aussprechbare Namen Wenn wir wieder an die Einführung denken, habe ich erwähnt, dass man Code wie ein Buch lesen können sollte. Es ist viel schwieriger etwas zu lesen, dass nicht aussprechbar ist. Abgekürzte Namen wie `AvgAmt` sollten vermieden werden. Sie sind vielleicht clevere Abkürzungen die für den Autor verständlich sind, beeinträchtigen das Leseerlebnis aller anderen Entwickler erheblich. ### Suchbare Namen Eine weitere Regel an die sich zu halten lohnt ist es, suchbare Namen zu verwenden. Eines der mächtigsten Tools in IDEs ist die Suche nach Elementen. Nehmen wir das obige Beispiel noch einmal: Wir haben eine Funktion die alle genügenden Noten zählt. Wir erinnern uns nicht mehr an den Namen, wissen aber noch, dass die Zahl 4 genutzt wurde. Suchen wir nun nach 4, ist es viel unwahrscheinlicher, dass wir fündig werden, weil diese Zahl nichts aussagt und öfters vorkommen kann. Wenn wir die Zahl jedoch auslagern in eine Konstante *_satisfactoryGrade* ist es viel einfacher nach dieser Stelle zu suchen. ### Namen der Lösungsdomäne Es ist unwahrscheinlich, dass ein nicht-Informatiker den Code lesen wird. So macht es auch Sinn, informatikbezogene Begrifflichkeiten zu verwenden um die Bedeutung besser wiederzugeben. Gerade bei der Verwendung von Design Patterns sollten die endsprechenden Namen verwendet werden. So ist beispielsweise *PersonFactory* für die meisten Entwickler verständlich, *PersonCreator* jedoch nicht konkret. ### Name der Problemdomäne Wenn keine Begriffe in der Lösungsdomäne existieren macht es Sinn, Begrifflichkeiten aus der Problemdomäne zu verwenden. Es kann davon ausgegangen werden, dass zukünftige Leser mit der Problemdomäne bekannt sind und es kann den Wert eines Namens erheblich steigern wenn passende Begriffe verwendet werden. ## Schlechte Namen vermeiden ### humorvolle Namen Es mag vielleicht im Moment als humorvoll erscheinen, *slaughter()* anstelle von *kill()* zu verwenden. Es sollte jedoch vermieden werden, da ein anderer Entwickler den Witz und somit den Code möglicherweise nicht versteht. ### Wortspiele Jegliche Art von Wortspiel sollte vermieden werden. Sie sind nicht auf den ersten Blick verständlich und auch hier wieder kann ein Unverständnis des Wortspiels zu Problemen führen. ### überflüssiger Kontext Es ist gut, wenn viele Details im Namen mitgegeben werden. Zu viele Informationen können jedoch schädlich für den Code sein. Es sollte nur so viel Kontext mitgegeben werden, wie nicht direkt erkennbar ist. ## Kategorien ### Klassennamen Klassen und Objekte sollten ein Substantiv oder einen substantischen Ausdruck als Namen haben. Ein Klassenname sollte niemals ein Verb enthalten. ### Methodennamen Methodennamen sollten aus einem Verb oder einem Ausdruck zusammen mit einem Verb bestehen.