Infoportal
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| software:programmierrichtlinien:java [2010-10-15 14:05] – angelegt zueger1 | software:programmierrichtlinien:java [Unbekanntes Datum] (aktuell) – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1 | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== Programmierrichtlinien für Java ====== | ||
| - | |||
| - | ===== Namensgebung ===== | ||
| - | ^ Namen für ^ beginnen mit ^^ Beispiele ^ | ||
| - | | Konstanten | Substantiv | Kleinbuchstaben | size, pwm, serialVersionUID | | ||
| - | | System-Konstanten | | | PORTF, FPSCR, DDR, PI ((Konstanten aus Reference-, User- Manuals, etc. werden wenn möglich so übernommen, | ||
| - | | Variablen | Substantiv | Kleinbuchstaben | version, wordSize | | ||
| - | | | Adjektiv | Kleinbuchstaben | full, ready | | ||
| - | | Fuktionen | Substantiv | Kleinbuchstaben | length() | | ||
| - | | | Adjektiv | Kleinbuchstaben | full(), equal()((Name bezeichnet Fuktionswert))| | ||
| - | | Methoden | Verb | Kleinbuchstaben | drawLine()((Imperativ))| | ||
| - | | Klassen | Substantiv | Grossbuchstaben | File, FifoQueue, Stack | | ||
| - | | Pakete | Substantiv | Kleinbuchstaben | java.io, ntb, target.ppc555 | | ||
| - | |||
| - | **Namenslänge: | ||
| - | |||
| - | **Sprache: | ||
| - | |||
| - | **Worttrennung: | ||
| - | |||
| - | ===== Kommentare ===== | ||
| - | Kommentieren Sie, was nicht im Programm steht (und wichtig ist). Vermeiden Sie Kommentare, die nur | ||
| - | das wiederholen, | ||
| - | Wählen Sie für Kommentare wennmöglich dieselbe Sprache wie für Namen im Programm. Aus den oben | ||
| - | geschilderten Gründen sind englische Kommentare vorteilhaft. | ||
| - | Verwenden Sie javadoc-konforme Kommentare für Klassen, Felder und Methoden, z.B. | ||
| - | <code java> | ||
| - | /** A stack of integer. | ||
| - | * Implements a LIFO data structure of fixed length, .... | ||
| - | */ | ||
| - | public class Stack { | ||
| - | /** indicates stack overflow. | ||
| - | * This flag may be checked after a push() operation. | ||
| - | * If overflow == true, the parameter of the most recent push() operation was ignored. | ||
| - | */ | ||
| - | public boolean overflow; | ||
| - | ... | ||
| - | |||
| - | /** pushes the value item onto the stack. | ||
| - | * The overflow flag tells if the operation was successful. | ||
| - | */ | ||
| - | public void push (int item) {...} | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | Verwenden Sie Trennkommentare zur Einleitung von Anweisungsfolgen, | ||
| - | erfüllen, z.B. | ||
| - | |||
| - | <code java> | ||
| - | //---- Read input array | ||
| - | In.open(" | ||
| - | int len = In.readInt(); | ||
| - | int [] a = new int[len]; | ||
| - | for(int i = 0; i < len; i++) a[i] = In.readInt(); | ||
| - | |||
| - | //---- Invert array | ||
| - | invert(a); | ||
| - | |||
| - | //---- Print inverted array | ||
| - | for(int i = 0; i < len; i++) Out.print(a[i] + " "); | ||
| - | Out.println(); | ||
| - | </ | ||
| - | |||
| - | Halten Sie die Anweisungsfolgen einer Methode möglichst frei von Kommentaren. Jedesmal, wenn Sie einen Kommentar schreiben, sollten Sie sich überlegen, ob Sie nicht stattdessen das Programm vereinfachen oder bessere Namen wählen können, um dadurch den Kommentar zu vermeiden. Ein gutes Programm ist nicht eines, das möglichst viele Kommentare enthält, sondern eines, das möglichst wenige Kommentare benötigt. Falls Sie dennoch einmal einen Algorithmus ausführlich kommentieren wollen, tun Sie das im Kopfkommentar der Methoden und Klassen und nicht zwischen den einzelnen Anweisungen. Bei zu vielen Kommentaren zwischen den Anweisungen kann es sein, dass Sie das Programm vor lauter Kommentaren nicht mehr sehen. | ||
| - | |||
| - | ===== Einrückungen ===== | ||
| - | Verwenden Sie als Einrückungstiefe 1 Tabublatorzeichen oder 2 Leerzeichen. Zu tiefe Einrückungen sind genauso unleserlich wie zu wenig tiefe oder gar keine Einrückungen. Die folgenden Codemuster zeigen, wie Sie Programmkonstrukte einrücken sollten: | ||
| - | ==== Anweisungen ==== | ||
| - | <code java> | ||
| - | if(cond) { | ||
| - | ... | ||
| - | } else if(cond) { | ||
| - | ... | ||
| - | } else { | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | <code java> | ||
| - | switch(expr) { | ||
| - | case c1: | ||
| - | ... | ||
| - | case c2: | ||
| - | ... | ||
| - | default: | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | <code java> | ||
| - | try { | ||
| - | ... | ||
| - | } catch(Exeption1 e) { | ||
| - | ... | ||
| - | } finally { | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | <code java> | ||
| - | while(cond) { | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | <code java> | ||
| - | do { | ||
| - | ... | ||
| - | } while(cond); | ||
| - | </ | ||
| - | |||
| - | <code java> | ||
| - | for(...) { | ||
| - | ... | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | ==== Klassen ==== | ||
| - | <code java> | ||
| - | class C { | ||
| - | ... static fields (Klassenfelder) and class constructors ... | ||
| - | ... instance fields (Instanzfelder) ... | ||
| - | ... constructors ( (Objket-)Konstruktoren ) ... | ||
| - | ... methods (Methoden) ... | ||
| - | } | ||
| - | |||
| - | ==== Methoden ==== | ||
| - | <code java> | ||
| - | public static int func() { | ||
| - | ... declarations (Deklarationen) ... | ||
| - | ... statements (Anweisungen) .... | ||
| - | } | ||
| - | |||
| - | Normalerweise sollten Sie jede Anweisung in eine eigene Zeile schreiben. Falls jedoch mehrere kurze Anweisungen zusammengehören und eine Einheit bilden, können Sie sie in die gleiche Zeile schreiben, z.B. | ||
| - | <code java> | ||
| - | p.next = head; head = p; | ||
| - | if (a > b) max = a; else max = b; | ||
| - | </ | ||
| - | Auf diese Weise wird der Programmtext kürzer, was oft auch dazu führt, dass er besser überschaubar ist. | ||
| - | |||
| - | ===== Programmkomplexität ===== | ||
| - | Unter der (statischen) Komplexität eines Programms versteht man die Schwierigkeit, | ||
| - | |||
| - | Eine Methode sollte keinesfalls länger als eine Bildschirmseite sein. Falls eine Methode länger ist, sollten Sie sie in kleinere Methoden zerlegen. Vermeiden Sie aber Extreme. Programme, die aus Hunderten von Methoden bestehen, die alle nur ein bis zwei Zeilen lang sind, sind ebenfalls schwer zu verstehen, weil der Leser ständig zwischen den einzelnen Methoden hin und her springen muss. | ||
| - | |||
| - | Um auch längere Methoden kompakt zu halten, sollten Sie keine überlangen Namen verwenden und Anweisungen, | ||
| - | |||
| - | ===== Testhilfen ===== | ||
| - | Moderne Programmierumgebungen verfügen meist über einen Debugger, der ihnen erlaubt, ein Programm Anweisung für Anweisung auszuführen und sich dazwischen die Werte der Variablen anzusehen. Trotz dieser bequemen Hilfe kann es nützlich sein, in ihr Programm Hilfsdrucke einzubauen, die ihnen zum Beispiel den Inhalt einer komplizierten Datenstruktur am Bildschirm oder noch besser auf eine Datei ausgeben. Hilfsdrucke sind kein Ersatz für einen Debugger, aber eine sinnvolle Ergänzung. Sie stellen Informationen kompakt und übersichtlich dar, wie Sie es mit einem Debugger kaum erreichen können. | ||
| - | |||
| - | Hilfsdrucke sollten auch nach dem Testen eines Programms nicht gelöscht werden. Sie können sie entweder auskommentieren oder noch besser mit einem Hilfsdrucke-Schalter ausblenden, z.B. | ||
| - | |||
| - | <code java> | ||
| - | if (debug) { | ||
| - | Out.println(" | ||
| - | Node p = head; | ||
| - | while (p != null) { | ||
| - | Out.println(p.val + " "); p = p.next; | ||
| - | } | ||
| - | Out.println(); | ||
| - | } | ||
| - | </ | ||
| - | |||
| - | Die Abfrage des Schalters debug kostet kaum Laufzeit und kann selbst in einem ausgetesteten und an den Kunden ausgelieferten Programm erhalten bleiben. Dies hat den Vorteil, dass man Hilfsdrucke beim Auftreten eines Fehlers jederzeit wieder aktivieren kann. Wenn Sie es so einrichten, dass der debug-Schalter per Kommandozeilenparameter gesetzt werden kann, brauchen Sie zum Einschalten das | ||
| - | Programm nicht einmal neu zu übersetzen. | ||
| - | |||
| - | Natürlich ist es auch möglich mehrere verschiedene solcher debug-Schalter anzulegen. Damit ist esmöglich, je nach Art des Problems die Hilfsdrucke auszuwählen, | ||
| - | |||
| - | Hat das Programm die geforderte Qualität erreicht, können diese debug-Schalter als Konstanten deklariert werden. Damit sieht der Compiler, dass diese Anweisungen in keinem Fall mehr durchlaufen werden und wird deshalb die Schalter-Abfrage wie auch die entsprechenden Anweisungen nicht mehr | ||
| - | übersetzen. D.h. Hilfsdrucke in ihrem Programm belegen weder Platz im Arbeitsspeicher des ausführenden Rechners, noch benötigen sie wertvolle Ausführungszeit: | ||
| - | |||
| - | ** Deklaration der Schalter während der Test- und Integrationszeit: | ||
| - | <code java> | ||
| - | public static boolean dbgN = true; | ||
| - | </ | ||
| - | ** Deklaration der Schalter nach der Test- und Integrationszeit: | ||
| - | <code java> | ||
| - | public static final boolean dbgN = false; | ||
| - | </ | ||
| - | ===== Plausibilitätsprüfungen ===== | ||
| - | Wenn ein Programm an einer bestimmten Stelle Annhamen über Parameterwerte oder deren Zustand von Datenstrukturen macht, dann sollten diese Annahmen auch überprüft werden. Java bietet zu diesem Zweck die assert-Anweisung an. | ||
| - | <code java> | ||
| - | assert x >= 0 && x <= 100; | ||
| - | </ | ||
| - | oder | ||
| - | <code java> | ||
| - | assert x >= 0 && x <= 100: "x is out of range [0..100]"; | ||
| - | </ | ||
| - | |||
| - | Aehnlich wie Hilfsdrucke sollten auch assert-Anweisungen nicht nur beim Testen verwendet werden, sondern auch in fertigen Programmen enthalten bleiben. Die Prüfungen werden ja nur ausgeführt, | ||
| - | |||
| - | Sie werden staunen, wie oft diese Plausibilitätsprüfungen Fehler selbst in ausführlich getesteten Programmen aufdecken. Plausibilitätsprüfungen helfen, Fehler frühzeitig aufzudecken und nicht erst dann, wenn sie sich fortgepflanzt haben und sich an ganz anderer Stelle im Programm auswirken. | ||
| - | |||
| - | Man nennt diesen Programmierstil defensives Programmieren. Ein Programmierer kann nie vorsichtig genug sein. Selbst erfahrene Programmierer machen Fehler, die oft beim Testen nicht entdeckt werden und erst im Betrieb eines Programms zum Vorschein kommen. Plausibilitätsprüfungen schaffen ein ruhiges Gewissen. Sie wirken wie " | ||
| - | Programmierers auch wirklich immer gelten. | ||
| - | |||
| - | ===== Weiterführende Links ===== | ||
| - | * [[ http:// | ||