»In der Informatik gibt es nur zwei echte Probleme: Cache-Verwaltung und Namensgebung.«
—Phil Karlton, Netscape-Programmierer
Viele nicht so gute Programmierer weigern sich, ihre wertvolle Lebenszeit auf das Ausdenken von Variablen- oder Funktionsnamen zu verwenden. Sie wollen schnell ein Ergebnis sehen und auf dem Weg dorthin nicht aufgehalten werden. Also wählen sie einen Namen, der gerade gut zu passen scheint und kurz und knapp ist, zum Beispiel tmp
oder var1
. Notfalls sogar dings
.
Andere stutzen, wenn sie eine Variable oder Funktion benennen sollen. Sie fühlen, dass hier etwas Großes passieren soll, etwas, das den Fortgang des Projekts beeinflussen wird. Die Entscheidung fällt ihnen schwer, der gewählte Funktionsname könnte ja unvorteilhaft sein. Bei der nächsten Funktion wiederholt sich das gleiche Spiel. Tage später stellt sich dann heraus, dass der erste Name gar nicht so recht zum zweiten passen will, es drückt und kneift alles. Aber jetzt ist es zu spät, eine Angleichung der Namen würde vermutlich Probleme verursachen.
Wer schon einmal mit sich gerungen hat, ob die Umbenennung einer Variable wirklich den Aufwand lohnt, wer sich gefragt hat, ob er lieber ganz kurze oder lieber aussagekräftigere Namen verwenden soll, und wer in fremdem Code Namensmonstern wie lpszStreetNameKey
begegnet, hat vermutlich das nagende Gefühl, dass eine Auseinandersetzung mit diesem Thema eine gute Sache sein könnte.
Die Namen von Klassen und Exceptions stehen also in CamelCase, für globale Variablen verwendet man Großbuchstaben, alles andere schreibt man klein und mit Unterstrichen getrennt.
Ein Problem, das auch besseren Programmierern immer wieder zu schaffen macht, ist der konsistente Umgang mit Komposita, d.h. mit Begriffen, die aus mehreren Wörtern bestehen. Im Deutschen schreibt man Begriffe wie Dateiname oder Hintergrundfarbe zusammen. Im Englischen jedoch heißt es korrekt: file name und background color. Während Letzteres in der freien Wildbahn als backgroundColor
oder background_color
auftaucht, also immer getrennt geschrieben wird, ist die Sache im Fall von file name weniger eindeutig: Die Schreibweisen getFileName
und getFilename
bzw. get_filename
und get_file_name
ringen um die Vormachtstellung. Wenn man jedoch eine Ausnahme für filename
macht, wie schreibt man dann filePath
? Und wie heißt die Variable, die den Namen des Lieblingstiers beinhaltet, favoriteAnimalname
?
Dieses Problem berührt den Grundsatz, dass Funktionsnamen und Variablennamen einem konsequenten Schema folgen sollten, damit sie erratbar sind und der Programmierer Zeit spart. Man orientiert sich dann generell an einem bestimmten Prinzip und merkt sich nur noch das Prinzip anstelle der Namensdetails. Im Sinne dieser Konsequenz empfehlen wir, alles, was sich als eigenes Wort verstehen lässt, mit einem Großbuchstaben bzw. Unterstrich abzuteilen, also getFileHandleForPathName
bzw. get_file_handle_for_path_name
zu schreiben.
Auch auf die Frage, ob Variablennamen im Singular oder im Plural stehen sollten, gibt es keine allgemein akzeptierte Antwort. Wenn eine Sammlung benannt werden soll, also zum Beispiel ein Array, das die Farben red
, green
, blue
und yellow
enthält, liegt es nahe, dieser Sammlung einen Namen im Plural zu geben, denn schließlich enthält sie mehrere Dinge. Andererseits verwendet man die Einzelteile dieser Sammlung später oft im Singular: if (isPrimaryColor(colors[$i])) ...
Manche Programmierer argumentieren, dass ein Singularname sich hier grammatikalisch ordentlicher anfühlt, andere ziehen es vor, dem Namen der Variable direkt entnehmen zu können, dass sie mehrere Dinge enthält. Versuchen Sie auch hier, sich für eine Variante zu entscheiden (oder die Ihres Teams zu übernehmen) und dann konsequent dabei zu bleiben.
Wie ein Funktions- oder Variablenname geschrieben wird und formal aufgebaut sein soll, ist ein vergleichsweise kleines Problem, das sich – inklusive der Suche nach einer sprachspezifischen Anleitung – in einer halben Stunde für immer lösen lässt. Die Suche nach passenden Namen hingegen ist schwieriger und beschäftigt Programmierer ein Leben...