Kurzeinstieg Java: Programmierstil

Was sind Programmierstile? Bearbeiten

Programmierstile legen fest, wie Java-Quelltext zu formatieren ist. Dabei geht es nicht um die Funktion ihres Programms, sondern um das Aussehen. Wir haben drei 'Hallo-Welt'-Beispiele vorbereitet.

Ein Extrembeispiel spart an Leerzeichen,

class Hallo{public static void main(String[]args){System.out.println("Hallo, Welt!");}}

ein Beispiel, bei dem die Blockklammern untereinander gesetzt wurden,

class Hallo
{
    public static void main(String[] args)
    {
        System.out.println("Hallo, Welt!");
    }
}

und ein Beispiel, das so formatiert wurde, wie die meisten Quelltexte in diesem Buch.

class Hallo {
    public static void main(String[] args) {
        System.out.println("Hallo, Welt!");
    }
}

Alle drei Beispiele führen dasselbe Programm aus. Nun hat jeder Programmierer seine eigenen Vorlieben. Es haben sich zwei^[1] Firmenstandards herausgebildet. Das sind zum Einen die von Sun veröffentlichten "Code Conventions for the Java Programming Language", die hoffnungslos veraltet^[2] sind. Zum Anderen der "Google Java Style", den Sie unter http://google-styleguide.googlecode.com/svn/trunk/javaguide.html finden.

Diese "Standards" sind nicht demokratisch legetimiert und so bilden sich innerhalb von Unternehmen, Abteilungen, Universitäten, Fachbereichen, einzelnen Seminaren und Programmiererforen eigene Programmierstile heraus, die sich in Details unterscheiden.

In diesem Kapitel stellen wir in Beispielen den "Google Java Style" vor. Wenn Sie in diesem Buch außerhalb dieses Kapitels Quelltexte finden, die dem nicht entsprechen, dann dürfen Sie nach Herzenslust meckern oder korrigieren, wobei das Korrigieren die für das Buch bessere Alternative ist.

Ein Tipp fürs Leben haben wir noch: Sie sollten niemals(!) über "den richtigen Programmierstil" diskutieren. Die Lebenswochen, die mit solchen Diskussionen ins Land gehen, bekommen Sie nicht zurück. Halten Sie sich in Foren, Universitätsseminaren und so fort einfach an den gegebenen Programmierstil und stecken Sie ihre Leidenschaft in korrekten Code.

Die sich hier anschließenden Abschnitte sind einige wichtige Punkte zum Programmierstil.

↑ Falls Sie weitere Standards kennen, dann immer herein damit ins Buch.
↑ vergl. http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Aufbau von Java-Dateien Bearbeiten

Java-Dateien enden auf '.java' und beinhalten Unicode-Zeichen. Jede Klasse mit Zugriff public befindet sich in einer eigenen Datei.

Die Reihenfolge der Dateiinhalte ist:

Kommentar mit Copyright-Informationen, falls es die gibt
package-Ausdruck, falls es den gibt
import-Anweisungen, falls es Importe gibt. Importe beziehen sich immer auf genau eine Klasse. Verwenden Sie keine "*"-Importe.
genau eine public-Klasse.

Beispiele

/* Copyright by John User */

package user.lang.java;

import meine.spezielle.Klasse;
import meine.spezielle.AndereKlasse;

public class Testklasse {
…
}

Aufbau von Klassen Bearbeiten

Konstruktoren gehören zusammen,
weitere Methoden werden nach logischen Gesichtspunkten geordnet,

class Matrix {

  // Konstruktoren
  public Matrix() {…}

  public Matrix(final int zeilen, final int spalten) {…}

  // Treppennormalformmethoden
  public void addiereZeileZuZeile(final int zeileQuelle, final int zeileZiel){…}

  public void tauscheZeileMitZeile(final int zeileQuelle, final int zeileZiel){…}

  public void multipliziereZeileMitZahl(final double zahl){…}

  // Multiplikationsmethoden
  …
}

Regeln zur Benennung Bearbeiten

CamelCase

Bezeichner bestehen aus ASCII-Zeichen,
Paketnamen aus durch Punkte getrennte Worte in Kleinbuchstaben
Klassennamen sind Nomen und beginnen mit einem Großbuchstaben. Mehrere Nomen werden mit Binnenmajuskeln zusammengeführt (class BuchSeitenVorlage) (engl. UpperCamelCase)
Methodennamen sind Verben oder Verb-Nomen-Kombinationen. Sie beginnen mit einem Kleinbuchstaben, Teilworte werden mit Binnenmajuskeln ergänzt (engl. lowerCamelCase). Die Verben stehen im deutschen Sprachgebrauch im Imperativ (liesBuch()).
Namen von Konstanten werden durchgängig großgeschrieben, Teilworte werden durch Unterstriche getrennt (ANZAHL_STECHMUECKEN_IN_SCHWEDEN).
Methodenparameter werden klein und mit Binnenmajuskel geschrieben, Parameternamen, die nur aus einem einzelnen Zeichen bestehen, sind zu vermeiden.

Blockklammern Bearbeiten

Verwenden Sie Blockklammern auch dann, wenn sie optional sind. Das betrifft beispielsweise bedingte Verzweigung mit einer einzeiligen Anweisung,
setzen Sie Blockklammern bei catch auf folgende Weise: } catch(…) {, dasselbe gilt für else
nach jeder öffnenden Klammer folgt eine neue Zeile,
die schließende Blockklammer liegt unter dem ersten Zeichen des Ausdrucks, der beendet wird.

Einrückungen Bearbeiten

Jeder Block erhöht die Einrückung um genau 2 Leerzeichen,

Beispiele

if (Bedingung) { // neuer Block beginnt
␣␣Anweisung1();
␣␣if (noch eine Bedingung) { // weitere Blockebene
␣␣␣␣mehrAnweisungen();
␣␣}
}

Leerzeilen Bearbeiten

zwischen zwei Methoden in der Klasse,
im Methodenkörper, wenn zusammengehörige Bereiche dadurch kenntlich gemacht werden können.

Leerzeichen Bearbeiten

Leerzeichen stehen

zwischen reservierten Schlüsselwörtern (catch, if, …) und einer öffnenden Klammer (,
vor jeder öffnenden Blockklammer {,
nach jeder schließenden Blockklammer, wenn weitere Elemente auf der Zeile folgen (} else {),
nach ',', "'", und ':', und der schließenden Klammer von Typumwandlungen
beidseitig um //, : in einer for-each-Schleife,

Hierbei gibt es Ausnahmen bei Anmerkungen (engl. annotation) und mehrdimensionalen Feldern mit nur einem Element.

Spezielle Formatierungen Bearbeiten

Die Elemente einer einfachen Aufzählung kommen in eine Zeile,
es wird nur eine Variable pro Zeile deklariert,
Felder werden so deklariert, dass die eckigen Klammern sich dem Typ und nicht dem Namen anschließen,
switch()-Blöcke enthalten immer einen default-Bereich,
numerische Literale (z. B. 100L) werden immer mit Großbuchstaben ergänzt, sofern sie überhaupt Buchstaben enthalten.

Kommentare Bearbeiten

Kommentare, die mit // … gebildet werden (Zeilenkommentare) brauchen nicht exakt untereinanderstehend ausgerichtet zu werden. Vor und nach dem Kommentarzeichen steht ein Leerzeichen.
Blockkommentare werden mit /* Kommentar */ gebildet. Jede neue Zeile im Blockkommentar beginnt mit einem Sternchen-Leerzeichen '*␣'. Sternchen stehen untereinander. Das erste Kommentarzeichen '/' ist auf die gleiche Weise eingerückt, wie der Ausdruck, auf den sich der Kommentar bezieht.

Googles Java Style schreibt übrigens nicht vor, was kommentiert werden soll.

Beispiele

if (Bedingung) { // Kommentar
  Anweisung; // Kommentar, nicht ausgerichtet
} // Ende von if

class Element {

  /* Ein Kommentar
   * über mehrere
   * Zeilen
   */
  Element() {
    …
  }

  /* 
   * Das gleiche
   * nochmal
   */
  Element(String elementName) {
    …
  }
}

Dokumentationskommentare Bearbeiten

Einleitung mit /**
Schluss mit */
Jede Klasse wird mit dem Kommentar /** beschrieben. Dies hat einen wichtigen Grund: Mit dem Dokumentationsprogramm javadoc werden diese speziellen Kommentare ausgelesen und zu einer html-Dokumentation zusammengefasst. Ein gutes Beispiel ist die offizielle Java-API http://java.sun.com/j2se/1.5.0/docs/api/ Sie wurde mit dem javadoc-Programm erstellt - und somit auch mit den Kommentarkonventionen geschrieben.

Vor allem anstehende Aufgaben sollte man mit TODO kennzeichnen, um nicht zu vergessen, dass an der vermerkten Stelle noch etwas zu berichtigen ist

Zeilenlänge Bearbeiten

Im Grunde genommen gibt es aus DOS-Zeiten eine Minimaleinschränkung von 80 Zeichen. Bei den größeren Displays heutzutage sind aber Zeilenlängen von 120 Zeichen aber schon in Ordnung. Unschön kann jedoch der Ausdruck von Code auf Papier werden. Daher sollte man sich mit Bedacht auf eines festlegen!

[1] Falls Sie weitere Standards kennen, dann immer herein damit ins Buch.

[2] vergl. http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

[1]

[2]