gute zeilen schlechte zeilen, jug ostfalen 29.8.2013

Gute Zeilen, schlechte Zeilen

Regeln für wartbare Programme

Java User Group Ostfalen, 29.08.2013

Dirk Weil, GEDOPLAN GmbH

Dirk Weil

GEDOPLAN GmbH, Bielefeld

Java EE seit 1998

Konzeption undRealisierung

Vorträge

Seminare

Veröffentlichungen

2Gute Zeilen, schlechte Zeilen

3

GUTE

SCHLECHTE

ZEILEN

ZEILEN


Gibt es guten und schlechten Code?

Software ist (fast) nie fertig

Software wird (meist) im Team entwickelt

Teams ändern sich über die Zeit

Software muss verständlich sein


Gibt es guten und schlechten Code?

Entwicklerteams sind meist heterogen

Berufserfahrung

Programmierstil

…

Richtlinien helfen

bei der Einarbeitung in fremde Software

bei der (Weiter-) Entwicklung


Richtlinien

6

Low Level: Namen, Formatierung …

Grundlegendes Klassendesign

Code-Komplexität

Anwendungsstruktur


Statische Code-Analyse

Matching des Codes gegen Regelsätze

Einfache (Text-)Pattern … strukturelle Pattern

7

Checkstyle


Dokumentation

Javadoc für API

Klassen, Interfaces,Methoden, Variablen

public , protected

Kontrolle bspw. per CheckstyleJavadoc Comments

Prüft per Default auch private� scope = protected

Getter/Setter-Doku meist überflüssig� allowMissingPropertyJavadoc = true


Dokumentation

API-Dokumentationveröffentlichen

Source-Jars erzeugen,z. B. mit Maven

ermöglicht Unter-stützung durchdie IDE

9

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-source-plugin</artifactId>

<inherited>true</inherited>

<executions>

<execution>

<id>attach-sources</id>

<phase>verify</phase>

<goals>

<goal>jar-no-fork</goal>

</goals>

</execution>

</executions>

</plugin>


Dokumentation

Erklärungsbedürftige Codesequenzen

Trivialdokumentation ist überflüssig

10

/*

* Fahrstrassen innerhalb von Fahrstrassen expandieren, d. h. durch ihre Elemente

* ersetzen. Dies geschieht in einer Schleife solange, bis alle Expansionen

* erledigt sind oder kein Fortschritt mehr erzielt wird.

*/

int letzteAnzahlFahrstrassenFahrstrassen = 0;

int anzahlFahrstrassenFahrstrassen = 0;

while (true)

{

for (Fahrstrasse fahrstrasse : this.fahrstrassen)

…

// Neue Weichenstellung protokollieren

this.logger.trace(this + ": setStellung(" + stellung + ")");


Namen

Klassen, Variablen, Methoden entsprechend ihrer Aufgabe benennen

spart umfangreiche Dokumentation

Well-Known Names nicht umdeuten!

Anschauungsbeispiel: "Nothalt-Funktion"

Anlagenstatus ist zu generell

Methode setzt den Status nicht, sondern toggelt

setXyz ist well-known mit anderer Bedeutung

11

public void setAnlagenstatus()

{

Anlagenstatus.getInstance().changeAnlagenstatus();


Namen

Keine Präfixnotation für Typen, Sichtbarkeit etc.:

Präfixnamen tendieren zur Unlesbarkeit

this. ist aussagekräftiger (OO) als m_

Unterscheidung Klasse vs. Interface zweitrangig

werden durch IDE-Unterstützung mehr als ersetzt

12

Instanzvariable Name beginnt mit m_

Variable vom Typ List<Integer> Name beginnt mit lI_

Interface Name beginnt mit I

… …


Namen

CS kann Namenskonventionen prüfen(Module group Naming Conventions )

IDE-Komfort nutzen!

Quick fix: Namensvorschläge (Variablen, Konstanten ..)

Save actions: Member mit this. qualifizieren

…


Formatierung

Code sollte im Team einheitlich formatiert sein

Einrückung (Tab/Blanks, wie viele?)

Platzierung von {

Zeilenumbruch

…

Vorteile

Code liest sich leichter

kleinere Change Sets im SCM

Lässt sich mit IDE-Komfort leicht erreichen

Save action : Format code


equals , hashCode

equals definieren � hashCode definieren

nicht nur equals(MyType)

Codeanalyse:

CS: Equals and Hashcode , Covariant Equals

FB: Class defines equals and uses Object.hashCode


equals , hashCode

Jedes Geschäftsobjekt sollte equals und hashCode definieren

IDEs bieten gute Unterstützung

Achtung bei equals in Basisklassen

16

public class BadEquals

{

public boolean equals(Object obj)

{

…

if (getClass() != obj.getClass())

// if (!(obj instanceof BadEquals)) // unsymmetrisch, wenn Subklasse überschreibt

// if (obj.getClass() != BadEquals.class) // funktioniert nicht für Subklassen

{

…


switch

Regeln:

default nicht vergessen

kein Fall Through

CS: Missing Switch Default, Fall Through


Protokollierung

keine Protokollausgabe auf stdout , stderr

"Mal schnell 'ne Ausgabe"

Achtung: IDE-Templates!

CS: Regexp…mit passendem Pattern


Exception-Verwendung

Werfen und Fangen von Throwable , Exception , RuntimeException i. A. fehlerhaft

CS: Illegal Catch , Illegal Throws


DRY

Keine Copy&Paste-Programmierung

CS: Strict Duplicate Code(nicht wirklich empfehlenswert)


Komplexität

Klassen / Methoden nicht zu lang

Anzahl Methodenparameter nicht zu groß

CS: Maximum Method Length , Maximum Parameters , Maximum File Length , Cyclomatic Complexity(Anwendung imTeam diskutieren!)


Einfach machen

Einfache Lösungen sind gute Lösungen

Vorsicht bei:

Reflectionextrem schlecht lesbar

Refactoring problematisch

hochgradig konfigurierbaren Klassenschwer nutzbar (bspw. GridBagConstraints )

übermäßigem Einsatz von Typparametern


Einfach machen

Anschauungsbeispiel: Entity Editor

Generischer Editor für Geschäftsobjekte

Steuerung per Annotation @Editable

Remote funktionsfähig (� kein EntityManager )

Hochgradige Nutzung von Reflection

Umfangreiche Konfiguration von Services etc.

Einsatzfall BDE-System

ca. 35 Entities


Klassen sparen lohnt nicht

Anschauungsbeispiel "Wachdienst":

Gebäudekontrolle durch Prüfung aller Räume

Räume sind auf Etagen verteilt

Kontrollierte Räumewerden abgehakt



Anschauungsbeispiel "Wachdienst"

1. Ansatz: Keine Klasse für Etage

Dialogaufbau unnötig kompliziert(~ Gruppenwechsel)

Kein Platz für zukünftige Erweiterungum Etagen-Daten



Anschauungsbeispiel "Wachdienst"

Besser: Zusätzliche Ebene für Etagen

Klares KonzeptReal World � Klasse


Wohin mit der Logik?



Anschauungsbeispiel "Modellbahnsteuerung":

Reservieren einer Fahrstraße=Stellen der betroffenen

Weichen und Signale

Fahrstrasse liegt alsGeschäftsobjekt vor

Anforderung als Webservice




1. Ansatz: Iteration über Fahrstraßenelemente im Webservice

Nachteile:nicht wieder-verwendbar, daim Webservice

"Polymorphiefür Arme"(instanceof~ goto der OO)

29

@POST

@Path("/fahrstrasse/{bereich}/{name}/reserviert")

public Response setFahrstrassenreservierung(...)

{

Fahrstrasse fahrstrasse = …

for (FahrstrassenElement fe

: fahrstrasse.getElemente())

{

Fahrwegelement fwe = fe.getFahrwegelement();

if (fwe instanceof Weiche)

{

Weiche w = (Weiche) fwe;

w.setStellung(…);

}

…




Besser: Platzierung der Logik in Fahrstrasse,abstrakte Methode statt expliziter Typabfrage

30

@Path("{bereich}/{name}/reserviert")

@POST

public Response setReserviert(…)

{

Fahrstrasse fahrstrasse = …

fahrstrasse.setReserviert(reserviert);

}

public void setReserviert(boolean reserviert)

{

for (FahrstrassenElement element : this.elemente)

element.setReserviert(reserviert);

public abstract void setReserviert(boolean reserviert);



Geschäftslogik in Geschäftslogik-Schicht

CDI, EJB, JPA, …

Präsentationslogik bspw. in JSF-Beans

CDI-Models, Managed Beans

Boundary-Code in EJBs, Webservices etc.

Saubere Schichtung

erhöht Wiederverwendbarkeit

macht den Code übersichtlicher


In Objekten denken

Anschauungsbeispiel: 1:n-Relation (JPA)

Query "Suche Books eines Publishers"(Warum so kompliziert?):

32

@Entity

public class Publisher

{

@Id @GeneratedValue Integer id;

@OneToMany(mappedBy = "publisher") List<Book> books;

…

@Entity

public class Book

{

@Id @GeneratedValue Integer id;

@ManyToOne Publisher publisher;

Publisher publisher = …;

… em.createQuery("select b from Book b where b.publisher.id=:publisherId", Book.class)

.setParameter("publisherId", publisher.getId())

.getResultList();


Packages

Zwei Anti-Beispiele


Anekdoten

34

String name = new String();

name = "Hugo";

if (val != null && ("" + val.getClass().getName()).equals("java.lang.String"))

Set<String> texte = …;

Set<Object> labels = new TreeSet<>();

labels.addAll(texte);

int adr = …;

String adrAsString = new Integer(adr).toString();

Offensichtlich komplett falsche Vorstellungvon Objekten und Referenzen darauf

instanceof

Sind die Labels nicht Texte? Warum dann Set<Object> ?Wenn unterschiedliche Typen erlaubt: Set<?>

Integer.toString(adr)


Anekdoten

35

public void changeRichtung()

{

if (isRueckwaerts())

setRueckwaerts(false);

else

setRueckwaerts(true);

}public class Anlagenstatus

{

private static Anlagenstatus anlagenstatus = null;

private Anlagenstatus() { }

public static Anlagenstatus getInstance()

{

if (anlagenstatus == null)

anlagenstatus = new Anlagenstatus();

return anlagenstatus;

}

setRueckwaerts(!isRueckwaerts())

public static final Anlagenstatus = new Anlagenstatus()

Noch besser: enum-Singleton


Anekdoten

36

@POST

@Path("artikel/{artNr}/menge")

public Response setSpeed(@PathParam("artNr") String adrNr,

@FormParam("menge") String menge)

{

try

{

int mengeInt = Integer.parseInt(menge);

…

}

catch (NumberFormatException e)

{

Auto car1 = ...;

Auto car2 = ...;

if (car1.getId().getValue().equals(car2.getId().getValue()))

{

...


int menge

if (car1.equals(car2))

Anekdoten

37

if (this.kommPunkt.isTurnText()) {

g2.setFont(system.getKommPunktFont());

g2.translate(kommPunktBreite / 2 + 2, 0 * kommPunktBreite / 2 - 1);

g2.rotate(Math.toRadians(this.kommPunkt.getDisplayWinkel() - 90),

this.kommPunkt.getDisplayX(), this.kommPunkt.getDisplayY());

g2.setColor(system.getColor(system.PROPERTY_KOMMPUNKT_TEXT_COLOR));

g2.drawString(this.kommPunkt.getId().getValue(), this.kommPunkt.getDisplayX() - 3,

this.kommPunkt.getDisplayY() + 2);

g2.setTransform(this.father.baseTransform);

} else {

g2.setFont(system.getKommPunktFont());

g2.translate(kommPunktBreite / 2 + 2, 0 * kommPunktBreite / 2 - 1);

g2.rotate(Math.toRadians(this.kommPunkt.getDisplayWinkel() - 90),

this.kommPunkt.getDisplayX(), this.kommPunkt.getDisplayY());

g2.setColor(system.getColor(system.PROPERTY_KOMMPUNKT_TEXT_COLOR));

g2.drawString(this.kommPunkt.getId().getValue(), this.kommPunkt.getDisplayX() - 24,

this.kommPunkt.getDisplayY() + 2);

g2.setTransform(this.father.baseTransform);

}


Qualitäts-Schulden

Schlechte Code-Qualität = Kredit

Code-Review + Korrektur = Rückzahlung

Weiterentwicklung trotz Schwächen = Zinszahlungen

können überwältigend werden!

Nichts tun = "absaufen"

Ad-hoc-Maßnahmen sind keine Dauerlösung

38 Gute Zeilen, schlechte Zeilen

Mehr?

Seminare zum Thema Java SE und Java EE, z. B.

Java Effective

Power Workshop Java EE

http://ips-it-schulungen.de/Kurse/Java

Fragen!

[email protected]


gute zeilen schlechte zeilen, jug ostfalen 29.8.2013

Documents