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

Präsentation zum Thema: "Entwicklungsrichtlinien für Java-Software PG-AQUASIUM Michael Weking"—  Präsentation transkript:

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

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

3 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

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

5 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

6 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

7 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

8 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

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

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

11 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

12 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

13 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

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

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

16 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

17 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

18 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

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

20 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

21 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

22 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

23 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

24 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

25 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

26 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