Prof. Dr. Pape - Java Programmierrichtlinien - Variablen

Deutsch

Namenskonventionen - Variablen

Zurück zur Übersicht

Die meisten der folgenden Regeln gelten auch für die Bezeichnung von Attribute und Parameter. Es ist allgemein aber immer von Variablen die Rede.

Anfangsbuchstabe kleinschreiben

Schreibe Variablen klein (Ausnahme sind Konstanten). Besteht eine Variable aus mehren Teilwörtern, so wird bei jedem folgenden Teilwort der erste Buchstabe groß geschrieben.
Begründung: Ein Bezeichner ist dadurch im Quelltext sofort als Variable erkennbar.

Beispiel

manfredMueller, anzahlPersonen, quersumme

Begründung

Der erste Buchstabe einer Variablen wird immer klein geschrieben, um sofort Variablen von Klassen unterscheiden zu können: analog zur Gross-/Kleinschreibung von Substantiven und den anderen Wortarten im Deutschen.

Konstanten mit Grossbuchstaben schreiben

Regel: Konstanten (static final) werden immer mit Grossbuchstaben bezeichnet und Teilwörter mit dem Unterstrich _ abgetrennt.
Begründung: Ein Bezeichner ist dadurch im Quelltext sofort als Konstante erkennbar.

Beispiel

ERD_GRAVITATION, LICHTGESCHWINDIGKEIT

Begründung

Symbolische Konstanten sind dadurch sofort im Quelltext als solche zu erkennen. Diese Regel gilt aber nur für primitive Datentypen oder Klassen, deren Objekte unveränderlich sind (z.B. String). Da bei Java Klassen immer Referenztypen sind, wird ist nur die Referenz konstant nicht aber der Wert (das Objekt). Bei veränderlichen Objekten sollte man besser nicht final verwenden und dann auch nicht die Großschreibung: der Leser nimmt sonst fälschlicherweise an, dass auch das Objekt und nicht nur dessen Referenz unveränderlich ist.

Substantive verwenden

Verwende (mindestens ein) Substantiv für Variablen.
Begründung: Die Bedeutung der Daten wird deutlich.

Beispiel

name, alter, studentImErstenStudiensemster, MAXIMALE_ANZAHL

Person student;

Person [] studenten;

Begründung

Variablen sind Platzhalter für Daten. Diese Daten haben einen Bezug zu Objekten oder Objekteigenschaften in der Wirklichkeit: die Bedeutung dieser Daten. Diese ist immer sehr gut durch ein Substantiv beschreibbar, welche die Bedeutung der Daten in der Realität ausdrücken. Wenn die Variable wie bei einem Feld mehrer Werte des Typs enthalten kann, so sollte man die Mehrzahl verwenden, ansonsten die Einzahl.

Zählvariablen

Regel: Verwende die Buchstaben i, j, k, l für rein technische ganzzahlige Schleifenvariablen.
Begründung: Aus historischen Gründen.

Beispiel

for (int i = 0; i < personen.length; i++) {
   … 
} 

Für die Aufzählung aller Elemente eines Feldes oder einer Datenstruktur des Java Collection Frameworks, sollte aber möglichst die ab JDK 5.0 zusätzliche for-Schleife verwendet werden. Die technischen Schleifenvariablen werden dann ganz vermieden:

for (Person person : personen) {
  …
}

Begründung

In den frühen Programmiersprachen wie COBOL, FORTRAN und deren Abkömmlinge wie ABAP oder BASIC gab es außer elementaren Datentypen für die Organisation komplexerer Daten eigentlich nur Felder oder etwas Analoges. Strukturen wie ein Record, ein struct oder eine Klasse entstanden erst in ALGOL und dessen Abkömmlingen. Integers als Indizes waren deswegen sehr häufig in Quelltexten anzutreffen und hatten oft wenig Bezug zu realen Daten. Suggestiv wurde dann meist i(nteger) als Name für die erste Indexvariable verwendet. Bei Verschachtlung von Schleifen hat man einfach den nächsten Buchstaben im Alphabet verwendet. Bei FORTRAN I waren alle Variablen mit Präfixe i,k,k,l automatisch Integer-Variablen.

this Objektattributen voranstellen

Regel: Um besser zwischen Objektattribute und lokalen Variablen zu unterscheiden, sollten Objektattribute mit this referenziert werden.
Begründung: Die Quelltexte werden lesbarer und Fehler werden vermieden.

Beispiel

this.name = name; // wobei name ein Parameter ist

Begründung

Durch diese Regel kann auch oft vermieden werden, sich unnötigerweise für einen Parameter, der das gleiche bedeutet wie ein Attribut, einen neuen Namen auszudenken. Manchmal findet man in Quelltexten eine an die Ungarische Notation angelegte Variante, in der die Präfixe s_ und m_ oder einfach s und m jeweils statische- und member-Variablen (Objektattribute) und -Methoden unterscheiden. Dies sollte vermieden werden, da auch ohne diese nicht jedem geläufigen Abkürzungen derselbe Nutzen mit this bei Objektattributen und vorangestelltem Klassennamen bei Klassenvariablen erreicht wird.

Durch diese Konvention können auch Fehler vermieden werden, die dadurch entstehen, dass eine lokale Variable oder ein Parameter ein Attribut gleichen Namens unbeabsichtigt verdeckt.

Ungarische Notation vermeiden

Regel: Verwende keine Ungarische Notation.
Begründung: Damit Quelltexte lesbarer und wartbarer werden.

Begründung

Bei der Ungarischen Notation werden zwei Präfixe dem eigentlichen Bezeichner vorangestellt: Der erste für den Verwendungszweck des Bezeichners, der zweite für den Typ. Zum Beispiel p für Pointer, i für Integer: piAnzahl ist ein Zeiger auf einen Integerwert.

Die Begründung für diese Regel scheint widersprüchlich, da die Ungarische Notation ja der Lesbarkeit dienen soll. Dies gilt allerdings eher für nicht typisierte Sprachen. Es gibt allerdings auch verschiedene Varianten der Ungarischen Notation, so dass die Abkürzungen nicht jedem geläufig sind. Viele der Präfixe für den Verwendungszweck, wie p für Pointer, machen in Java auch gar keinen Sinn. Sehr viele Programmierer verwenden auch gar nicht diese von Charles Simonyis entwickelte Notation, sondern eine Vereinfachung und Abwandlung aus der Windowswelt (Visual Basic, Excel). Bei dieser Variante ist der Präfix nur eine Codierung des Typs und nicht des Verwendungszwecks. In Java – aufgrund sehr eingeschränkter Überladung von Operatoren und sehr strengen Typisierung – ist der Typ der Variablen in den meisten Fällen ohnehin aus dem Kontext ersichtlich. Ansonsten bieten alle modernen Entwicklungsumgebungen die direkte Anzeige des Typs und der zugehörigen Javadoc, so dass die Ungarische Notation der Lesbarkeit bei Javaprogrammen eher schadet als nutzt. Neben der Lesbarkeit leidet aber auch die Wartbarkeit der Quelltexte bei Verwendung der Ungarischen Notation in typisierten Sprachen: Da Typinformationen an zwei Orten – sowohl in der Deklaration als auch im Bezeichnernamen – enthalten sind, werden diese Informationen bei häufigen Änderungen des Quelltextes erfahrungsgemäß inkonsistent: wird der Datentyp von double nach int geändert und im Präfix diese Änderung nicht nachgeführt, so enthält der Quelltext nun irreführende Informationen.