Hallo Spaß-Coder,
im Artikel Basics? Kenn‘ ich doch schon! haben wir begründet, warum grundlegende Programmierpraktiken sinnvoll und hilfreich sind.
Eine dieser Basics ist die Regel, für alles möglichst aussagekräftige Namen zu finden. Darüber möchten wir im folgenden ein wenig sprechen.
Aussagekräftige Namen
Wieso steht an der Methode eigentlich nicht dran, was sie macht? Kennt ihr das, Methoden haben kryptische, wenig aussagekräftige Namen und beim Blick auf den Inhalt der Methode gibt es einige Überraschungen? Wer hat schon einmal den Variablennamen „clazz“ verwendet? Doof, dabei wäre „class“ doch besser – ist aber leider schon belegt. Es gibt ein paar kleinere Hilfen die dabei helfen, einen guten Namen zu finden.
CamelCase nutzen
Unsere Klassen und Funktionsnamen setzen sich in aller Regel aus mehreren Wörtern zusammen. Damit diese beim Lesen von Code sich leichter erfassen lassen, sollten die Wortteile voneinander getrennt werden. Dazu verwenden wir am besten das CamelCasing (oder die Binnenmajuskel, wie wir es im Deutschen nennen…wer denkt sich sowas eigentlich aus?). Dabei werden neue Worte immer mit einem Großbuchstaben begonnen, ohne sie durch ein Leerzeichen zu trennen (was wir in unseren Programmiersprachen ja nicht dürfen).
So lässt sich createdefaultconfiguration deutlich schlechter lesen, als das in CamelCase geschriebene CreateDefaultConfiguration.
CamelCase lässt sich leichter Lesen und Schreiben, als die Verwendung anderer Trennmethoden, etwa Unterstriche (create_default_configuration).
Aussprechbare Bezeichner vergeben
Namen sollten aussprechbar sein, vor allen, wenn man im Team arbeitet. So ist es viel einfacher, mit dem Kollegen über InitialReputationValueOfOwner zu sprechen, statt sich mit IniRepVOO die Zunge zu verbiegen (sprecht es mal aus…), auch wenn es lang erscheint. Auch Abkürzungen eignen sich nicht immer gut. Kann man sich beim Lesen (mit entsprechender Vorkenntnis) vielleicht noch denken, dass doB_ddmmyy das Geburtsdatum in der Form Tag-Monat-Jahr ist, kann man mit dateOfBirthAsDayMonthYear genauso viel anfangen aber besser darüber reden.
Beim Schreiben der langen Namen unterstützt uns unsere IDE durch Code-Ergänzungen, auch das ist also kein Grund für Abkürzungen.
Substantive für Klassennamen
Vermeiden sollten wir bei Klassen allzu allgemeingültige Namen wie Manager, Processor, Data, Info oder gar Helper. Hier ist die Gefahr besonders hoch, dass wir diese Klassen mehr Aufgaben aufbürden, als sie haben sollten. Nach dem Single Responsibility Principle sollte eine Klasse genau eine Aufgabe haben. Eine Klasse mit dem Namen TileManager verleitet z. B. dazu, dass hier alle Möglichen Verwaltungsaufgaben zu einem Tile unterzubringen. Dabei wäre es sicher besser, verschiedene Aufgaben auf verschiedene Klassen aufzuteilen, etwa TileFactory, TileComparer, TileCollider, TileRepository, …
Insbesondere, wenn wir eins der bekannten Design Pattern umsetzen, sollten wir die Klassen auch so benennen, wie sie im Pattern verwendet werden. Das erhöht den Wiedererkennungswert und erleichtert das Verständnis für jeden, der das Pattern ebenfalls kennt.
Verben im Methodennamen verwenden
Methoden erfüllen eine Aufgabe. Aus diesem Grund soll die Aufgabe auch im Namen der Methode auftauchen, damit wir auf den ersten Blick genau wissen, was die Methode macht. So wirt mir bei der Benutzung der Methode CreateDefaultConfiguration() sicher sofort klar, was sie tut. Würde die Methode nur Default() heißen, muss ich erst die – wahrscheinlich sowieso nicht gut gepflegte – Klassendokumentation lesen oder in den Code der Klasse selbst schauen. Beides hält mich auf uns kostet Zeit, ist also nicht wirtschaftlich. Diese Zeit spare ich, wenn der Name zuvor gut gewählt wurde.
Ein Wort pro Konzept
Beim Finden von Namen sollte man sich angewöhnen, für gleiche Aufgaben auch gleiche Namen zu verwenden. Das führt zum einen zu einheitlichen Namen, in denen man sich besser zurecht findet – vor allem, wenn die Code-Basis wächst. Zum anderen unterstützt das weitere Punkte, auf die wir im Artikel Funktionen noch eingehen werden.
So sollten die Getter einer Klasse immer getXX heißen. Haben wir eine Methode, die z. B. einen Wert aus in einer Liste suchen soll, sollte de Methode nicht GetValue(string value) sondern besser findValueByName(string name) heißen. Gleiches gilt, wenn die Informationen von woanders geholt werden, etwa dem Dateisystem. Die Methode getXMLFile(string filename) ist dann erlaubt, wenn es eine Klassenvariable XMLFile gibt. Muss die Methode die Datei erst aus dem Dateisystem oder einem Webservice auslesen, ist fetchXMLFile(string filename) der bessere Name. So kann ich als Verwender der Methode auch gleich erkennen, wie groß der zu erwartende Aufwand der Methode ist (ein get geht immer schnell und wirft keine Fehler, ein fetch oder find dauert ggf. und ich muss mit zu behandelnden Fehlern rechnen).
Domänenspezifische Begriffe verwenden
Wenn ich Code für bestimmte fachliche Zwecke schreibe, dann sollte ich auch die Sprache der Fachleute verwenden, für die die Software gedacht ist. Sagen wir mal, wir schreiben eine Software zur Verwaltung von Kochrezepten, dann sollten wir auch die Begriffe Rezept, Zutat und Kochbuch verwenden. Typischerweise schreiben wir unseren Code in englisch. Wenn die Domäne, in der wir uns bewegen aber nicht in englisch ist, und uns die Begriffe nicht bekannt sind, dann ist es hier durchaus erlaubt, auch die deutschen Domänenbegriffe zu verwenden. Auch wenn sich findRezeptByZutaten(List<Zutat> zutatenToSearch) ein wenig seltsam anhört, ist es besser, als zwanghaft englisch zu verwenden, auch wenn man mit den Worten recipe und ingredient nichts anfangen kann…oder benutzen wir doch eher addition… oder beides, je nachdem, wer es gerade programmiert?
Hierbei ist es vor allem im Team wichtig, dass die Begriffe einheitlich verstanden und verwendet werden. Es sollte also eine Einigung im Team geben, ob deutsch oder englisch verwendet wird und welche Begriffe genau was bedeuten. Ggf. ist es hilfreich (bei umfangreichen Domänen vielleicht sogar notwendig) ein Glossar anzulegen.
Möglichst sofort den besten Namen verwenden
Gute Namen zu finden ist nicht immer leicht. Es ist aber empfehlenswert, sich direkt beim Anlegen einer Klasse, Methode oder Variable kurz innezuhalten und sich Gedanken über den Namen zu machen. Statt schnell den Klassenassistenten der IDE aufzurufen und eine Klasse mit dem Namen rrrr anzulegen sollten wir uns überlegen, was wir mit der Klasse anfangen möchten und ihr einen passenden Namen geben. Statt eine Variable mal eben asdf zu nennen, sollten wir uns überlegen welchen Zweck die erstellte Instanz erfüllt und sie entsprechend benennen. Statt alles in einen Namespace oder ein Package zu legen, das utils heißt, sollten wir uns überlegen, wo jemand anders – oder wir selbst in ein paar Wochen – die Klasse suchen würde.
Zusammenfassung
Haben in unserem Code alle verwendeten Objekte, einen passenden Namen und sind in passend benannten Strukturen abgelegt, finden wir uns viel schneller zurecht und können so viel schneller – und damit wirtschaftlicher – unseren Code lesen und auch verändern.
Wem so gar kein guter Name einfallen will, der holt sich bei http://www.classnamer.com/ einfach ein wenig Inspiration. Oder noch besser: einfach den ersten Namen verwenden, der generiert wird, das verkürzt die Zeit des Nachdenkens über den Namen und ist damit doch wirtschaftlicher, .. äh, oder?
[Hinweis: wer den letzten Satz nicht als solches erkannt haben sollte: das war ironisch gemeint, genauso wie der Classnamer an sich]
Viel Spaß beim Anwenden,
Eure Spaß-Coder