Schlechter Bezeichner
| 🚧 | Diese Seite befindet sich in Bearbeitung | 🚧 |
| 🤓 | Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 1 annotiert und ab Blatt 2 abgezogen wird. | 🤓 |
Beschreibung
Gute Bezeichner für Variablen, Klassen, Methoden, etc. sind der erste, wichtige Schritt um Quellcode verständlich zu gestalten. Zwar ist es unmöglich *alle* schlechten Bezeichner aufzuzählen, jedoch gibt es einige Regeln:
Einzelne Buchstaben
Innerhalb von Schleifen sind einzelne Buchstaben wie i, j und k erlaubt. Ähnlich dazu ist auch bei Koordinaten x und y erlaubt.
Statt n jedoch sollte man length oder size verwenden (oder natürlich etwas, was in dem Kontext des Quellcodes Sinn ergibt).
In der equals Methode wäre Beispielweise equals(Object o) nicht zulässig. Das lässt sich aber leicht beheben, indem man equals(Object other) oder equals(Object object) wählt.
Abkürzungen
Abkürzungen sollen vermieden werden, da deren Bedeutung nicht (immer) klar ist und dadurch der Quellcode unnötig schwer zu verstehen ist.
Beispiele hierfür sind:
obj statt object, scan statt scanner, num statt number, etc...
Nichtssagenden oder unspezifische Bezeichner
Nichtssagende oder unspezifische Bezeichner erschweren auch das lesen und verstehen des Quellcodes, da hier erst aus dem Kontext verstanden werden muss, wofür die Variable genutzt wird.
Beispiele hierfür sind:
something, variable, array, regex, error, pattern, ...
Unnötige Prä- oder Suffixe
Prä- bzw. Suffixe verlängern nur unnötig den Bezeichner, ohne diesem einen sinnvollen Informationsmehrwert zu geben. Im folgenden ist zum Beispiel klar, welcher Datentyp dem Bezeichner zugewiesen wird und muss nicht nochmal in dem Bezeichner festgeschrieben werden:
myArray statt array, passwordObj statt password, passwordList statt passwords, IInterface statt Interface, ...
Sehr ähnliche Bezeichner
Bei Bezeichnern die einen sehr ähnliche Bezeichner teilen, kann es schnell zu Verwirrung und Tippfehlern kommen, sowohl bei der entwickelnden Person, als auch der Person, die den Quellcode darauf hin versucht zu verstehen:
string1, string2, sTring1, ...
Bedeutungslose Konstanten
Zahlen und Zeichenketten (Strings) die fest im Quellcode enthalten sind, sollen als Konstante im Kopf der Klasse deklariert werden. Da diese Konstante im Quellcode verteilt ist, soll deren Bezeichner entsprechend aussagekräftig sein. Dadurch lässt sich auch später der Inhalt der Konstante leichter und vor allem überall gleichzeitig ändern. Sämtliche Regelungen von oben gelten auch für Konstanten.
Booleans
Um den Lesefluss des Quellcodes zu verbessern, ist es Norm einem Boolean ein Verb als Präfix zu geben. So sollte zu Beispiel statt on, isOn verwendet werden.
Negativbeispiel
public final class Main {
private final static int THREE = 3;
private Main() {
}
public static void main(String[] args) {
int[] integerArray = new int[THREE];
fillArray(integerArray, 9);
}
public static void fillArray(int[] one, int two) {
for (int i = 0; i < one.length; i++) {
one[i] = two + i;
}
}
}
1. Was wenn wir nicht mehr 3 als Index verwenden wollen? Dann müssten wir den Bezeichner der entsprechenden Konstante auch ändern im gesamten Quellcode. THREE = 4 würde dann nämlich auch keinen Sinn mehr ergeben. 2. integerNumber sagt nichts über die Verwendung der Variablen aus. 3. integerArray macht den Quellcode nur unnötig lang. Wir wissen, dass es ein Array aus Integern ist, weil direkt vornedran der Datentyp schon deklariert wurde.
Positivbeispiel
public final class Main {
private final static int CAPACITY = 3;
private final static int DEFAULT_VALUE = 9;
private Main() {
}
public static void main(String[] args) {
int[] relevantNumbers = new int[CAPACITY];
fillArray(relevantNumbers, DEFAULT_VALUE)
}
public static void fillArray(int[] array, int defaultValue) {
for (int i = 0; i < array.length; i++) {
array[i] = defaultValue + i;
}
}
}
Hier sind die Bezeichner aussagekräftig und eindeutig. Wir wissen direkt, ohne direkt den Wert der Konstanten anzuschauen, was die Konstante macht bzw. wofür sie da ist. Wir verstehen den Quellcode also ohne Probleme.