Galileo Computing < openbook >
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.


Java ist auch eine Insel von Christian Ullenboom
Buch: Java ist auch eine Insel (Galileo Computing)
gp Kapitel 26 Style-Guide
gp 26.1 Programmierrichtlinien
gp 26.2 Allgemeine Richtlinien
gp 26.3 Quellcode kommentieren
gp 26.3.1 Kommentartypen
gp 26.3.2 Strategischer und taktischer Kommentar
gp 26.3.3 Bemerkungen über JavaDoc
gp 26.3.4 Gotcha-Schlüsselwörter
gp 26.4 Bezeichnernamen
gp 26.4.1 Ungarische Notation
gp 26.4.2 Vorschlag für die Namensgebung
gp 26.5 Formatierung
gp 26.5.1 Einrücken von Programmcode - die Vergangenheit
gp 26.5.2 Verbundene Ausdrücke
gp 26.5.3 Kontrollierter Datenfluss
gp 26.5.4 Funktionen
gp 26.6 Ausdrücke
gp 26.7 Anweisungen
gp 26.7.1 Schleifen
gp 26.7.2 Switch, case und Durchfallen
gp 26.8 Reihenfolge der Eigenschaften in Klassen
gp 26.9 Zugriffsrechte und Zugriffsmethoden
gp 26.9.1 Accessors/Zugriffsmethoden
gp 26.10 Verweise


Galileo Computing

26.3 Quellcode kommentierendowntop

Jede Datei, die Quelltext in irgendeiner Form enthält, muss dokumentiert werden. Aus einigen einleitenden Zeilen muss deutlich werden, was der Quelltext macht. Daneben sollten auch Copyright-Informationen Platz finden. Kommentare in den öffentlichen Klassen müssen so verfasst sein, dass diejenigen, die die Klassen auch benutzen, etwas damit anfangen können. Somit hat die Dokumentation der Funktionalität eine ganz andere Qualität als die Dokumentation des Quelltexts, die in erster Linie für die Programmierer interessant ist.


Galileo Computing

26.3.1 Kommentartypendowntop

In Java gibt es drei Möglichkeiten für Kommentare:

gp Zeilenkommentare mit //
gp Blockkommentare mit /* */
gp Besondere Blockkommentare, die JavaDoc-Kommentare mit /** */

Ebenso wie einleitende Worte jede Datei beschreiben, geht die Dokumentation in der benutzten Klasse und den Funktionen weiter. Nach dem oberen Block, welcher die Datei als Ganzes beschreibt, folgen in der Regel die Definition des Pakets, dann die Import-Klauseln und anschließend die Deklaration der implementierten Klassen.

Alle Kommentare und Bemerkungen sollten in Englisch verfasst werden, um Projektmitgliedern aus anderen Ländern das Lesen zu vereinfachen. Für allgemeine Kommentare sollten wir die Zeichen // benutzen. Sie haben zwei Vorteile:

gp Bei Editoren, die Kommentare nicht farblich hervorheben - oder bei einer einfachen Quellcodeausgabe auf der Kommandozeile - lässt sich ersehen, dass eine Zeile, die mit // beginnt, ein Kommentar ist. Einen Quelltext zu übersehen, der für mehrere Seiten mit den Kommentarzeichen /* und */ unterbrochen wird, ist schwierig. Zeilenkommentare machen deutlich, wo Kommentare beginnen und wo sie enden.
gp Der Einsatz der Zeilenkommentare eignet sich besser dazu, während der Entwicklungs- und Debug-Phase Codeblöcke auszukommentieren. Benutzen wir zur Programmdokumentation die Blockkommentare, so sind wir eingeschränkt, denn Kommentare dieser Form können wir nicht schachteln. Zeilenkommentare können einfacher geschachtelt werden.

Ein weiterer Vorteil ist, dass Editoren Tastaturkürzel zum Kommentieren und Auskommentieren mitbringen. Bei Eclipse ist das etwa (Strg)+(/) und (Strg)+(\).


Galileo Computing

26.3.2 Strategischer und taktischer Kommentardowntop

Quellcode muss kommentiert werden. Die Kommentare sollten einfach zu finden und in natürlicher Sprache verfasst sein. Sind die Bezeichnernamen gut gewählt, so ist auch weniger an Quelltext zu kommentieren. Programmieren wir über eine längere Zeit, so müssen wir auch angeben, wann wir mit der Implementierung begonnen haben und wann wir Änderungen durchführen. Gerade deshalb ist es wichtig, mit JavaDoc zu arbeiten, denn die Dynamik eines Programms wird festgehalten und die externe Dokumentation ist immer aktuell. Kommentare können strategisch oder taktisch sein.


Hinweis Ein strategischer Kommentar beschreibt, was eine Funktion macht, und wird deshalb vor der Funktion platziert. Die strategischen Kommentare sind auch im von JavaDoc verwendeten DocStyle zu verfassen. Ein taktischer Kommentar beschreibt Programmzeilen und wird, wenn möglich, ans Ende der zu erklärenden Zeile gestellt.

Sicherlich ist nicht sofort ersichtlich, was eine Zeile wie j = i-- + ++i + i++ - --i so alles leistet. Vorsicht ist allemal gegeben, denn viele taktische Kommentare machen den Programmtext unleserlich. Wir sollten daher versuchen, viele Informationen im strategischen Kommentarblock unterzubringen und nur wirklich wichtige Stellen mit taktischen Kommentaren zu markieren. Der folgende Ausschnitt gibt Einblick in die Klasse BigInteger. Die Klasse gehört seit Java 1.1 zum API-Standard:

// Arithmetic Operations
/**
* Returns a BigInteger whose value is (this + val).
*/
public BigInteger add(BigInteger val) throws ArithmeticException {
if (val.signum == 0)
    return this;
else if (this.signum == 0)
    return val;
else if (val.signum == signum)
    return new BigInteger(plumbAdd(magnitude, val.magnitude),
                       signum);
else if (this.signum < 0)
    return plumbSubtract(val.magnitude, magnitude);
else  /* val.signum < 0 */
    return plumbSubtract(magnitude, val.magnitude);
}

Die gesamte Klasse zerfällt in mehrere Teile, wobei der obere Teil ein Auszug der arithmetischen Operationen ist. Die Gliederung der Datei in die verschiedenen Ebenen besteht natürlich nur im Quelltext, und Sun wählte, um dies deutlich zu machen, die Zeilenkommentare. Alles, was also mit // beginnt, gliedert den Quelltext. Das heißt aber auch, dass normale, also taktische Kommentare, mit den herkömmlichen Zeichen abgegrenzt werden.


Beispiel Ein taktischer Kommentar
else                      // val.signum < 0

Dieser Kommentar ist besonders gut, und wir kommen später noch einmal darauf zu sprechen, denn er erklärt den else-Teil der Fallunterscheidung. Auf den ersten Blick ist also zu sehen, wann dieses Codesegment ausgeführt wird.


Galileo Computing

26.3.3 Bemerkungen über JavaDocdowntop

JavaDoc erstellt aus den strategischen Kommentarzeilen

/**
 * Returns a BigInteger whose value is (this + val).
 */
 public BigInteger add(BigInteger val) throws ArithmeticException {

eine HTML-Datei, die Anwendern der Klasse einen Überblick über den Prototyp der Funktion gibt. Wir sehen sofort: Die Funktion ist public, sie trägt den Namen add, erlaubt einen Übergabeparameter vom Objekttyp BigInteger und gibt auch, wenn sie nicht gerade eine ArithmeticException auslöst, ein BigInteger zurück.

Es ist sehr nützlich, in die Kommentare HTML-Code einzubetten. Die gewöhnlichen HTML-Kommandos sind dabei zugelassen - Näheres dazu findet sich im vorhergehenden Kapitel über JavaDoc. Ein anderes Beispiel macht den Einsatz von DocComments mit HTML-Tags noch deutlicher und soll noch einmal eine gut kommentierte Klasse zeigen. Es handelt sich diesmal um die Klasse InetAddress:

/**
 * This class represents an Internet Protocol (IP) address.
 * <p>
 * Applications should use the methods getLocalHost,
 * getByName, or getAllByName to
 * create a new InetAddress instance.
 *
 * @author  Chris Warth
 * @version 1.42, 02/23/97
 * @see     java.net.InetAddress#getAllByName(java.lang.String)
 * @see     java.net.InetAddress#getByName(java.lang.String)
 * @see     java.net.InetAddress#getLocalHost()
 * @since   JDK1.0
 */
public final
class InetAddress implements java.io.Serializable {
   ...
}

Galileo Computing

26.3.4 Gotcha-Schlüsselwörtertoptop

Besondere Eigenschaften eines Quelltexts müssen hervorgehoben werden. Dazu dienen Kommentare, die aber in verschiedenster Form vorkommen. Es ist dabei nur von Vorteil, wenn die Kommentare in Kategorien eingeteilt werden: Diese Programmstelle ist besonders trickreich, die andere beschreibt eine mögliche Fehlerquelle und so weiter. Wir wollen spezielle Kommentarmarkierungen (Gotcha-Schlüsselwörter) verwenden, die später von Programmen weiterverarbeitet werden. So könnte ein kleines Shell-Skript schnell spezielle Schlüsselwörter heraussuchen und in einer Liste zusammenfassen. Diese Liste kann dann zur Nachbearbeitung nützlich sein.


Gotcha-Schlüsselwort Beschreibung
:TODO: topic Eine Programmstelle muss noch weiter bearbeitet werden.
:BUG: [bugid] topic Ein bekannter Fehler sitzt hier. Dieser muss beschrieben und, wenn möglich, mit einer Fehlernummer (Bug-ID) versehen werden.
:KLUDGE: Der Programmcode ist nur schnell zusammengehackt und muss überarbeitet werden. Leider eine zu häufige Programmiertechnik, die dazu führt, dass das Programm nur unter gewissen Bedingungen richtig läuft.
:TRICKY: Uns fiel etwas besonders Cleveres ein, und das sollten wir mitteilen. Denn wie sollten die anderen unseren Trick erkennen, ohne lange nachzudenken?
:WARNING: Warnt vor etwas, beispielsweise vor hohem Speicherverbrauch oder Zugriffsproblemen bei Applets.
:COMPILER: Baut um einen Compiler oder Bibliotheksfehler herum.

Tabelle 26.1 Gotcha-Schlüsselwörter und ihre Bedeutung

Die einzelnen Symbole sollten die ersten im Kommentar sein; anschließend sollte eine Zeile kurz das Problem erläutern. Bei der Entwicklung im Team sollten die Programmierer die von ihnen gemachten Anmerkungen durch ein Namenskürzel kenntlich machen. Ebenso ist das Datum zu vermerken (nach einer Zeit können Bemerkungen entfernt werden) und jeder, der den Quelltext geändert hat. So lässt sich insbesondere die Behebung von Fehlern dokumentieren.

// :TODO: ulliull 970702: give the program the last kick

<Eclipse: »Eclipse kennt zum Beispiel das Gotcha TODO:. Taucht es im Quellcode auf, so visualisiert Eclipse dies mit einem eigenen Symbol, was links neben dem Quellcode angezeigt wird.« >

Versionskontrollen-Verwaltungsprogramme wie CVS (Concurrent Versions System) erlauben ebenfalls nachzuvollziehen, welcher Autor wann eine Änderung vorgenommen hat.





Copyright (c) Galileo Press GmbH 2004
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de