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:

Bezeichner in anderen Sprachen

In der internationalen Programmieren-Community hat sich Englisch als Standard durchgesetzt. Auch unter ausschließlich deutschen Mitwirkenden ist es gängig sich nach dieser Konvention zu richten. Daher ist der komplette Quellcode auf Englisch zu verfassen und die Bezeichner entsprechend passend zu wählen.

Einzelne Buchstaben

Einzelne Buchstaben verstecken die Bedeutung einer Variable und sind demnach kontraproduktiv. Auch wenn es in for-Schleifen sehr oft passiert, dass i, j, und k für die Schleifenvariable verwendet wird, kann diese schnell nicht aussagekräftig sein. Besser wäre es, der Variablen einen genauen Bezeichner zu geben, zum Beispiel, was genau gezählt wird. Für Indizes eines 2D-Arrays eigenen sich zum Beispiel row und column.

Auch 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, ...

Es gibt auch vereinzelt Kontexte, die so allgemein sind, dass es schwierig wird, bessere Bezeichner zu finden. Als Beispiel dafür ist array im Positivbeispiel zu finden, obwohl es zuvor als unspezifischer Bezeichner aufgelistet wurde.

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, ...

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 DREI = 3;
    
    private Main() {

    }

    public static void main(String[] args) {
        int[] integerArray = new int[DREI];
        fillArray(integerArray, 9);
    }

    public static void fillArray(int[] one, int two) {
        for (int i = 0; i < one.length; i++) {
            one[i] = two + i;
        }
    }
}

• integerNumber sagt nichts über die Verwendung der Variablen aus.
• 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.

Mehr zu diesen Regelungen und Konventionen

• https://www.samanthaming.com/tidbits/34-better-boolean-variable-names/
• https://wiki.eclipse.org/Recommenders/CodingConventions#is_prefix_should_be_used_for_boolean_variables_and_methods