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

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

Embed Size (px)

Citation preview

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

Style Guides

Entwicklungsrichtlinien für Java-Software

PG-AQUASIUMMichael Weking

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

Style Guides 2

Verwendung von Richtlinien

1. Graphical User Interface (GUI)

2. (Java-) Programmcode

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

Style Guides 3

Grundidee

Problem:

Durch ungewohnte Formatierung von Code kann dessen Verständnis erheblich erschwert werden.

Lösung:

Einheitlicher („guter“) Programmierstil

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

Style Guides 4

Bestehender CodeÄnderung und Erweiterung

Dokumentation der Änderungen CVS (Java-) Quellcode ReadMe-Datei

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

Style Guides 5

Codierregeln (1/8)

main Methode In jeder Klasse zu Testzwecken erlaubt

Überladen von Methoden innerhalb der selben Klasse gestattet

(wenn sie semantisch das gleiche tun)

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

Style Guides 6

Codierregeln (2/8)

lokale Variablen Deklaration wo Initialwert bekannt ist bestehende besser nicht überschreiben

...for( int i = 0; i < 10; i = i + 1 )

{...}

...

Beispiel:

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

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.

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

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)

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

Style Guides 9

Codierregeln (5/8)

Klassenrumpf Klassenvariablen sparsam verwenden Zugriff auf Variablen grundsätzlich nur über Methoden

(d. h. keine „public“-Variablen)

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

Style Guides 10

Codierregeln (6/8)

Aufbau einer Methode:

Leitsatz: Schreibe kurze und hoch kohäsive Methoden!

Kopfkommentar

Methodendeklaration Methodenrump

f

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

Style Guides 11

Codierregeln (7/8)

ExceptionsAbfangen von unerwarteten

Bedingungen/Fehlern/Situationen/ZuständenProgramm bricht nicht ab, sondern läuft ab einem

definierten Wiedereinstiegspunkt weiter.

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

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 ) {}...

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

Style Guides 13

Einrückungen und Layout (1/4)

class DieEigentlicheKlassendeklaration

package ...

import ...

/* Kopfkommentar der Klasse */

Deklaration/Kommentierung der Variablen und Konstanten

/* Kopfkommentar der Methode */

void DieEigentlicheMethodendeklaration(...)

Deklaration/Kommentierung lokaler Var. und Konst.

... restlicher Methodencode

Klassendeklaration

Methodendeklaration

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

Style Guides 14

Einrückungen und Layout (2/4)

Trennen von zu langen Nachrichten:

...myView.doThis( withThat ... )

.andThat( withThose ...)

.andSomethingOther( withThoseFollowing ...);...

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

Style Guides 15

Einrückungen und Layout (3/4) Fallunterscheidungen

.../* Kommentar */if ( <Bedingung> )

{ /* ggf. Kommentar */Anweisung_1;...Anweisung_n;}

else if ( <Bedingung> ){ /* ggf. Kommentar */...}

else{ /* ggf. Kommentar */...};

...

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

Style Guides 16

Einrückungen und Layout (4/4)

.../* 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 };...

Korrektes Einrücken von Blöcken:

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

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(...) )

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

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)

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

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

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

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)

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

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

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

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() )

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

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() )

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

Style Guides 24

Namen und Bezeichner (8/9) Bezeichnung von formalen Parametern

Möglichkeit 1:

Bezeichnung der Rolle, die der formale Parameterfür die Methode jeweils spielt

void reshape( int xPosition,int yPosition,int width,int height)

...

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

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)...

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

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, ...)