Entwicklungsrichtlinien für Java-Software PG-AQUASIUM Michael Weking Style Guides Entwicklungsrichtlinien für Java-Software PG-AQUASIUM Michael Weking

Verwendung von Richtlinien 1. Graphical User Interface (GUI) 2. (Java-) Programmcode 1. GUI Benutzerfreundlichkeit Style Guides

Grundidee Problem: Lösung: Durch ungewohnte Formatierung von Code kann dessen Verständnis erheblich erschwert werden. Jeder kann sich im Code jedes anderen leichter orientieren. Richtlinien sind verbindlich. Soll von den Richtlinien abgewichen werden, dann nur aus triftigem Grund, der zu dokumentieren ist. Lösung: Einheitlicher („guter“) Programmierstil Style Guides

Bestehender Code Änderung und Erweiterung Dokumentation der Änderungen CVS (Java-) Quellcode ReadMe-Datei CVS: /* $Log: $ */ Style Guides

Codierregeln (1/8) main Methode Überladen von Methoden In jeder Klasse zu Testzwecken erlaubt Überladen von Methoden innerhalb der selben Klasse gestattet (wenn sie semantisch das gleiche tun) In jeder Klasse kann zu Testzwecken eine main Methode erzeugt werden. Dies erlaubt, die Funktionalität in Form eines Unittests oder Demos zu prüfen. Insbesondere beim Setzen von Werten bei Klassenvariablen ist Vorsicht geboten, da dies isoliert im Test zwar einwandfrei funktioniert, beispielsweise aber bei einer Integration im Gesamtsystem jedoch Probleme bereiten kann. Style Guides

Codierregeln (2/8) lokale Variablen Deklaration wo Initialwert bekannt ist bestehende besser nicht überschreiben Beispiel: ... for( int i = 0; i < 10; i = i + 1 ) { } Die Deklaration einer lokalen Variablen muss dort stattfinden, wo ihr Initialwert bekannt ist. Dies ist besonders bei Schleifen der Fall. Lokale Variablen sollten lieber neu deklariert und initialisiert werden, als Bestehende zu überschreiben/wiederzuverwenden. Fehlerquellen können so minimiert werden. Style Guides

Codierregeln (3/8) Blöcke in Schleifen und Bedingungen Continue und break müssen in Schleifen umsichtig verwendet werden Switch-Anweisungen müssen immer einen default case beinhalten Break muss jeden case einer switch-Anweisung beenden. Style Guides

Codierregeln (4/8) Import von Paketen Wahlloses Importieren sämtlicher Klassen eines Paketes (mittels *) sollte vermieden werden Punktnotation bei Uneindeutigkeit (z. B. java.awt.Frame) Style Guides

Codierregeln (5/8) Klassenrumpf Klassenvariablen sparsam verwenden Zugriff auf Variablen grundsätzlich nur über Methoden (d. h. keine „public“-Variablen) Style Guides

Codierregeln (6/8) Aufbau einer Methode: Kopfkommentar Methodendeklaration Methodenrumpf kohäsiv = zusammenhaltend Leitsatz: Schreibe kurze und hoch kohäsive Methoden! Style Guides

Codierregeln (7/8) Exceptions Abfangen von unerwarteten Bedingungen/Fehlern/Situationen/Zuständen Programm bricht nicht ab, sondern läuft ab einem definierten Wiedereinstiegspunkt weiter. Exceptions sind nicht dazu da, Bedingungen/Situationen/Zustände zu behandeln, die bei jedem regulären Programmablauf zu erwarten sind. Style Guides

Codierregeln (8/8) Beispiel für schlechten Programmierstil: ... int[] anArray = {3, 1, 2, 5, 4}; int sum = 0; try { for( int i = 0; i<Integer.MAX_VALUE; i = i + 1 ) sum = sum + anArray[i]; } catch( ArrayIndexOutOfBoundsException e ) {} Schlechtes Beispiel für Exceptionaufruf. Style Guides

Einrückungen und Layout (1/4) package ... import ... Klassendeklaration /* Kopfkommentar der Klasse */ class DieEigentlicheKlassendeklaration Deklaration/Kommentierung der Variablen und Konstanten Methodendeklaration /* Kopfkommentar der Methode */ void DieEigentlicheMethodendeklaration(...) Deklaration/Kommentierung lokaler Var. und Konst. ... restlicher Methodencode Style Guides

Einrückungen und Layout (2/4) Trennen von zu langen Nachrichten: ... myView.doThis( withThat ... ) .andThat( withThose ...) .andSomethingOther( withThoseFollowing ...); Style Guides

Einrückungen und Layout (3/4) Fallunterscheidungen ... /* Kommentar */ if ( <Bedingung> ) { /* ggf. Kommentar */ Anweisung_1; Anweisung_n; } else if ( <Bedingung> ) else }; Style Guides

Einrückungen und Layout (4/4) Korrektes Einrücken von Blöcken: ... /* Der True-Block ist zu lang für eine Zeile, der False-Block nicht. */ if ( rectangle.x() > rectangle.y() ) { /* True-Zweig der Bedingung */ rectangle.invert(); rectangle.placeUpRight(); } else { return false }; Style Guides

Namen und Bezeichner (1/9) Bezeichnerwahl möglichst selbsterklärend Verwendung von Grossbuchstaben gliedert Bezeichner, die aus mehreren Wörtern zusammengesetzt sind (z. B. handleEvent(...) ) Style Guides

Namen und Bezeichner (2/9) Bezeichner für Klassen, Klassenvariablen Beginnt mit einem Großbuchstaben Sollte etwas über die Bedeutung der Objekte verraten (wenig über die Implementierung) Style Guides

Namen und Bezeichner (3/9) Bezeichner für Konstanten keine Kleinbuchstaben (korrekt: PI, falsch: Pi) stehen am Beginn einer Klasse sind final Style Guides

Namen und Bezeichner (4/9) Bezeichner für lokale Variablen Exceptions: Kleinbuchstabe e Schleifenzähler: Kleinbuchstaben i, j, k Streams: Benannt in Bezug auf ihre Tätigkeit (also: in, out, inOut) Style Guides

Namen und Bezeichner (5/9) Benennung von Methoden Zustands- oder Zugriffsmethoden Benennung mit einem Substantiv. (z. B. length(...) ) Bei Bedarf: Voranstellung eines Adjektivs oder Präposition (z. B. currentState(...) ) Eventuell Voranstellen der Silbe get oder set Style Guides

Namen und Bezeichner (6/9) Benennung von Methoden Vergleichs- oder Prädikatmethoden Benennung unter Benutzung eines Verbs als Fragment eines Fragesatzes (z. B. intersects(), isInState(), isEquivalenceRelation() ) Style Guides

Namen und Bezeichner (7/9) Benennung von Methoden Aktionsmethoden Benennung unter Benutzung eines Verbs als Fragment eines Befehlssatzes (z. B. update(...), redraw(...), drawLine() ) Style Guides

Namen und Bezeichner (8/9) Bezeichnung von formalen Parametern Möglichkeit 1: Bezeichnung der Rolle, die der formale Parameter für die Methode jeweils spielt void reshape( int xPosition, int yPosition, int width, int height) ... Style Guides

Namen und Bezeichner (9/9) Bezeichnung von formalen Parametern Möglichkeit 2: Formale Parameter sind nach dem Basistyp bzw. der Basisklasse bezeichnet void name( String aString) ... Style Guides

Fazit Die „Normierung“ von Code führt zu Erhöhung der Übersicht Vermeidung von Fehlern Aber: Es gibt nicht nur eine mögliche „Normierung“ (Unterschiede von Firma zu Firma, Arbeitsgruppe zu Arbeitsgruppe, ...) Style Guides