MATZE WAS HERE …

Zur Zeit lese ich mit Begeisterung das Buch “Clean Code” von Robert C. Martin. Dies nehme ich zum Anlass in nächster Zeit mehrere Blogposts zu diesem Thema zu veröffentlichen.

Was ist sauberer Code?

Für mich hat sauberer Code folgende Eigenschaften, er ist:

• lesbar
• testbar
• modular
• nicht redundant

Aussagekräftige Namen

Damit der Code lesbar ist, empfiehlt es sich aussagekräftige Namen zu verwenden. “Uncle Bob” (aka Robert C. Martin) widmete diesem Thema das 2. Kapitel in seinem Buch.

Zu aller erst sollte man zweckbeschreibende Namen wählen. Der Name sollte also den Zweck beschreiben und dabei noch ausdrücken warum er existiert, was er macht und wie er benutzt werden soll.

Um bei der Namenswahl Fehlinformationen vermeiden zu können, ist es wichtig auf irreführende Namen, aber auch z.B. auf die einzelnen Kleinbuchstaben l oder den Großbuchstaben O, zu verzichten, da dies zu Verwechslungen führen kann.

Es kommt darauf an Unterschiede deutlich zu machen. Es sollte dabei vermieden werden den selben oder ähnlichen Namen für unterschiedliche Aufgaben zu benutzen und zum Beispiel “unbestimmte Leerwörter” wie Info und Data nicht als Namensanhang zu verwenden.

Ein weiterer Punkt ist das Verwenden von aussprechbaren Namen. Dafür sollten “verständliche umgangs- oder fachsprachliche Wörter” benutzt und Abkürzungen vermieden werden.

Wichtig für die korrekte Benamung ist es suchbare Namen zu verwenden, denn einzelne Buchstaben oder Zahlen sind bei einer Suche über den gesamten Code nur schwer zu finden. Es ist zum Beispiel einfacher MAX_TRANSFERS zu finden als die Zahl 3.

Die Codierung zu vermeiden ist ebenfalls ein Punkt um aussagekräfte Namen zu erhalten. Für Robert C. Martin ist es dabei unnötig die ungarische Notation zu verwenden, Member-Präfixe sind wenn man moderne IDE’s benutzt ebenso unnötig.

Der Leser sollte den Namen beim lesen nicht mental übersetzen müssen. Es ist zum Beispiel unsauber wenn im Code die Variable v verwendet wird und dabei mental in Volumen übersetzt werden muss. Daher sollte man mentale Mappings vermeiden.

Für die Benamung von Klassennamen gilt, dass diese keine Verben sein sollten, sondern “ein Substantiv oder substantivischer Ausdruck”. Dabei sollte man z.B. auf Manager, Processor, Data und Info als Namen bzw. Anhang verzichten. Im Gegensatz zu den Klassennamen sollten die Methodennamen ein Verb sein bzw. aus einem Ausdruck mit einem Verb bestehen.

Es macht auch wenig Sinn humorige Namen zu verwenden, da diese meist nicht den Zweck für die Verwendung wiederspiegeln. Ein Beispiel wäre hier eatMyShorts() für eine abort() Methode.

Des weiteren gilt: ein Wort pro Konzept, zum Beispiel sollte eine Methode zum Datenauslesen an einer Stelle nicht fetch() heißen, wenn an anderer Stelle im Code für das selbe Konzept retrieve() als Methodenname verwendet wird.

In aller Regel sollten die Namen der Lösungsdomän verwendet werden. Dabei sollte möglichst auf Fachbegriffe aus der Informatik, Algorithmennamen, Patternnamen oder mathematische Begriffe zurück gegriffen werden. Den Namen aus der Problemdomän zu verwenden, sollte man nur, wenn keine Fachbegriffe möglich sind.

Zusammenfassend kann gesagt werden, wenn man sich an diese wenigen Regeln hält, sollte man als Entwickler aussagekräftige Namen erhalten. Dies führt dann zu einem lesbareren und damit sauberern Code.