Java Standard: Programmierstil

Aus Wikibooks


Java Coding Conventions[Bearbeiten]

Bei Sun gab es vor 1999 Code Conventions. Nach der Übernahme durch Oracle wurden sie nicht erneuert. Die nachfolgenden Hinweise basieren darauf; viele Programmierer richten sich weiterhin danach.

Unabhängig davon legen viele Firmen ihre eigenen Regeln fest. Jeder Programmierer wird diesen Regeln folgen müssen.

Kommentare[Bearbeiten]

Kommentare beschreiben die Abläufe im Programm. Der Compiler übergeht sie, sie sind nur für den Menschen gedacht. Somit kann jede Art der Sprache verwendet werden. Aber ganz frei ist es auch nicht. Nur weil man alles damit machen kann und keine Fehlermeldung bekommt, heißt das noch lange nicht, dass es auch gut ist, was man geschrieben hat.

Schreibt die Kommentare so, dass sie für jeden Leser verständlich sind. Manche Sachen sind nur begrenzt für andere verständlich:

  • lokal/regional/national begrenzte Beschreibungen - Wenn Ihr euren Code im Internet veröffentlicht, macht es wenig Sinn, die Kommentare auf Deutsch zu schreiben. Damit werden viel weniger Menschen Euren Code anschauen! Die Lingua Franca des Internets ist nun mal Englisch, ob man das mag oder nicht.
  • Eigennamen, die nur Du verstehst - Auch das ist nicht sinnvoll. Vielleicht macht es Spaß Geheimnisse vor der kleinen Schwester zu haben, aber unter Programmierern ist das eher schwierig.

Es gibt drei Kommentarstile in Java:

Einzeilige Kommentare //[Bearbeiten]

Einzeilige Kommentare werden für kurze Beschreibungen benutzt. Diese sollten nicht die Syntax oder Sachen die der Programmierer auf den ersten Blick erkennt, erklären, sondern eher die Bedeutung einer Zeile für den Gesamtkontext.

Ein Codebeispiel sowie ein guter und schlechter Kommentar:

  • Code:
 Object beispiel = new Object();
  • schlechter Kommentar:
 //hier wird ein neues Objekt erstellt

Das hier ist ein schlechter Kommentar, weil ohnehin aus dem Quelltext hervorgeht, das hier ein neues Objekt erstellt wird. Dieser ist in der Regel beim Lesen von Quelltexten nur hinderlich - er muss mitgelesen werden, aber enthält keine wirklichen Informationen.

  • guter Kommentar:
 // Die Instanz beispiel wird benutzt, um ...

wobei die Pünktchen natürlich die Funktion des Objekts beschreiben sollten.

Dieser hier ist besser, da er erklärt wozu die Instanz verwendet wird, bzw. in welchem Zusammenhang das Objekt mit dem Programm steht.

Mehrzeilige Kommentare[Bearbeiten]

Einleitung mit /*
Schluss mit */

 Object beispiel = new Object();
 /* Hier wird das Objekt erstellt, mit dem nachher dies-und-jenes gemacht wird.
 Für den Gesamtkontext ist es deswegen wichtig, weil dings-und-dangs so-und-so ist.*/

Diese Kommentare werden wie die obigen benutzt, nur eben für komplexere Sachverhalte.

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

Sprechende Variablennamen[Bearbeiten]

Wenn Klassen, Variablen oder Methoden selbst geschrieben werden, sollten die Namen folgender Konvention folgen:

"sprechende" Namen[Bearbeiten]

Die Namen sollten "sprechend" sein. Auch wenn ein Fremder den Code anschaut, sollte er in etwa verstehen, wofür der Name steht. Bei diesem Fremden kann man aber davon ausgehen, dass er selber Java vom Ansatz her kann.

Sind mehrere Wörter im Namen zusammengefasst (z. B. Methode toString), so werden die Wörter gross und zusammen geschrieben. Die Regeln für die ersten Buchstaben wird weiter unten erklärt.

Klassen[Bearbeiten]

Klassen sollen groß geschrieben werden. Klassen sollen als Namen Nomen (Hauptwörter) besitzen. Also keine Verben, Adjektive, usw.

Methoden[Bearbeiten]

Methoden sollen aus einem Verb und einem Nomen bestehen, z. B. loescheDatei. Die Wörter werden wie in 1. erwähnt zusammen und gross geschrieben. Der Anfangsbuchstabe allerdings klein! Fällt Euch kein Nomen ein, ist es auch in Ordnung, wenn nur ein Verb benutzt wird.

Variablen/ Objekte/ Instanzen[Bearbeiten]

Diese drei sollen alle mit Nomen benannt werden. Auch hier soll der Anfangsbuchstabe klein geschrieben werden.

static final Variablen/Objekte/Instanzen[Bearbeiten]

Im Gegensatz zu ihren normalen Verwandten werden diese komplett groß geschrieben, um zu verdeutlichen, dass es sich hierbei um Konstanten handelt.

Verschachtelte Methodenaufrufe[Bearbeiten]

Auch wenn es für Euch manchmal keinen Sinn macht; schreibt eure Aufrufe von Methoden und Konstruktoren nicht alle ineinander. Drei Methoden pro Zeile sind schon genug, sonst leidet die Lesbarkeit sehr darunter. Wenn Ihr in euer eigenes Programm guckt, was Ihr vor einem halben Jahr geschrieben habt, findet Ihr euch selber manchmal nicht zurecht (Mir geht es so :-)). Da helfen klare Methodenaufrufe schon enorm.

Weitere Vorteile, jeden Aufruf in eine eigene Zeile zu schreiben:

  • Stack Traces mit Zeilennummer sind dann hilfreicher. z.B. ist eine NullPointerException mit der Nummer einer Zeile, in der mehrere Aufrufe stehen, mehrdeutig.
  • Mit einem Debugger kann man gezielter Breakpoints setzen.

Codeeinrückung[Bearbeiten]

Code sollte, und wird in praktisch allen Lehrbüchern und Codes, eingerückt geschrieben werden.
Die Grundregel dafür lautet in etwa: Bei jedem Anfang eines logischen Abschnitts wird eingerückt. Dies ist bei { geschweiften Klammern } auf jeden Fall so! Aber man kann auch eine Folge von Methodenaufrufen untergliedern.

Leerzeichen nehmen keinen Platz weg, der Computer ignoriert sie sowieso; also spart nicht mit Einrückungen.

Einrückungen kann man mit TABs oder mit Leerzeichen machen. Letztere haben den Vorteil, dass die Einrückungstiefe bei allen Werkzeugen gleich ist.

Leerzeilen[Bearbeiten]

Spart nicht mit Leerzeilen - damit sind keine 20 Zeilen nacheinander gemeint. Aber lasst ruhig nach jedem logischen Abschnitt ein bis zwei Zeilen frei. In einem Deutschaufsatz schreibt Ihr ja auch nicht alles aneinander, sondern Ihr lasst Absätze?!

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!