Vortrag Dirk Weil Gute zeilen, schlechte Zeilen auf der JAX 2012

Gute Zeilen, schlechte ZeilenRegeln für wartbare Programme

Dirk Weil | GEDOPLAN

Dirk Weil• GEDOPLAN GmbH, Bielefeld• Java EE seit 1998• Konzeption und

Realisierung• Vorträge

dirk.weil@gedoplan.de

• Vorträge• Seminare• Veröffentlichungen

2 Gute Zeilen, schlechte Zeilen

GUTEZEILEN

dirk.weil@gedoplan.de3 Gute Zeilen, schlechte Zeilen

SCHLECHTE

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

Gute Zeilen, schlechte Zeilen4

Gibt es guten und schlechten Code?• Entwicklerteams sind meist heterogen

– Berufserfahrung– Programmierstil– …

• Richtlinien helfen

• Richtlinien helfen– bei der Einarbeitung in fremde Software– bei der (Weiter-) Entwicklung

Richtlinien

Low Level: Namen, Formatierung …

Grundlegendes Klassendesign

Code-Komplexität

Anwendungsstruktur

Statische Code-Analyse• Matching des Codes gegen Regelsätze• Einfache (Text-)Pattern … strukturelle Pattern

dirk.weil@gedoplan.deGute Zeilen, schlechte Zeilen7

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-Dokumentation veröffentlichen

– Source-Jarserzeugen,z. B. mit Maven

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

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

<id>attach-sources</id>

– ermöglicht Unter-stützung durchdie IDE

<id>attach-sources</id>

<phase>verify</phase>

<goals>

</goals>

</execution>

</executions>

</plugin>

Dokumentation• Erklärungsbedürftige Codesequenzen

* 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;

• Trivialdokumentation ist überflüssig

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"

• Anschauungsbeispiel: "Nothalt-Funktion"

– Anlagenstatus ist zu generell

– Methode setzt den Status nicht, sondern toggelt– setXyz ist well-known mit anderer Bedeutung

public void setAnlagenstatus()

Anlagenstatus.getInstance().changeAnlagenstatus();

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

Instanzvariable Name beginnt mit m_

Variable vom Typ List<Integer> Name beginnt mit lI_

Interface Name beginnt mit I

… …

– Präfixnamen tendieren zur Unlesbarkeit(was wäre wohl der Präfix für Map<String, Lok> ?)

– werden durch IDE-Unterstützung mehr als ersetzt

– this. ist aussagekräftiger (OO) als m_

– Unterscheidung Klasse vs. Interface zweitrangig

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

– 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: ,

– 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

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

Cyclomatic Complexity(Anwendung imTeam diskutieren!)

Einfach machen• Einfache Lösungen sind gute Lösungen• Vorsicht bei:

– Reflection• extrem schlecht lesbar• Refactoring problematisch

• Refactoring problematisch

– hochgradig konfigurierbaren Klassen• schwer 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äume

werden abgehakt

Klassen sparen lohnt nicht• Anschauungsbeispiel "Wachdienst"

– 1. Ansatz: Keine Klasse für Etage

– Dialogaufbau unnötig kompliziert(~ Gruppenwechsel)

(~ Gruppenwechsel)– Kein Platz für zukünftige Erweiterung

um Etagen-Daten

Klassen sparen lohnt nicht• Anschauungsbeispiel "Wachdienst"

– Besser: Zusätzliche Ebene für Etagen

– Klares KonzeptReal World � Klasse

Real World � Klasse

Wohin mit der Logik?

Wohin mit der Logik?• Anschauungsbeispiel "Modellbahnsteuerung":

– Reservieren einer Fahrstraße= Stellen der betroffenen

Weichen und Signale– Fahrstrasse liegt als

Geschäftsobjekt vor

– Anforderung als Webservice

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

– Nachteile:

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

public Response setFahrstrassenreservierung(...)

Fahrstrasse fahrstrasse = …

– Nachteile:• nicht wieder-

verwendbar, daim Webservice

• "Polymorphiefür Arme"

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

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

public Response setReserviert(…)

fahrstrasse.setReserviert(reserviert);

public void setReserviert(boolean reserviert)

for (FahrstrassenElement element : this.elemente)

element.setReserviert(reserviert);

public abstract void setReserviert(boolean reserviert);

Wohin mit der Logik?• 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)

@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;

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

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

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

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

Anekdoten

public void changeRichtung()

if (isRueckwaerts())

setRueckwaerts(false);

setRueckwaerts(true);

}public class Anlagenstatus

public class Anlagenstatus

private static Anlagenstatus anlagenstatus = null;

private Anlagenstatus() { }

public static Anlagenstatus getInstance()

if (anlagenstatus == null)

anlagenstatus = new Anlagenstatus();

return anlagenstatus;

Anekdoten@POST

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

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

@FormParam("menge") String menge)

int mengeInt = Integer.parseInt(menge);

catch (NumberFormatException e)

Auto car1 = ...;

Auto car2 = ...;

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

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

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

dirk.weil@gedoplan.deGute Zeilen, schlechte Zeilen

Vortrag Dirk Weil Gute zeilen, schlechte Zeilen auf der JAX 2012

Documents

JAX 2011 - Garbage collection verstehen

Axis2, CXF und JAX-WS RI im Vergleich - OIO-Die …...3 5 © 2008 Orientation in Objects GmbH Axis2, CXF und JAX-WS RI im Vergleich JAX-WS WSEE JWS JAXB JSR-250 JAX-RPC JEE EJB Servlet

Grails - Die Suche hat ein Ende (JAX 2008)

Gute Fragen/ Schlechte Fragen

Gute KPIs - schlechte KPIs (Kevin Indig)

BENUTZERHANDBUCH - Brother...Bei einem 24 mm Band können maximal 7 Zeilen, bei einem 18 mm Band 5 Zeilen, bei einem 12mm Band 3 Zeilen, bei einem 9 mm und einem 6 mm Band 2 Zeilen,

· etertim og aurchoe en KUtü 'Vorgehe schlechte Zeilen Marie n ho/ Uns Verbotene Daily-Soaps seglcitende Falle Schloss Einstein Big Brother Erhebun

DIE SCHLECHTE HAUPTLEISTUNG

Schlechte Thomas

Tod durch PowerPoint - physik.hofkoh.dephysik.hofkoh.de/presentation/tod-durch-powerpoint.pdf · Präsentation schlechte Kommunikation schlechte Beziehungen. Machen wir die Welt zu

Gute Seiten, Schlechte Seiten - Webmontag Edition

W jax-2011-web klein

Mind the Gap - Architecture versus Code @ W-JAX 2016

Extreme Agile Leadership - Vortrag auf der JAX-Konferenz am 21.4.2015

W jax wenn-code altert

Concurrency-Modelle auf der JVM auf der w-jax 3.11.2015

Verlernte Agilität - JAX 2012

W-JAX 2013 Spring Batch - Performance und Skalierbarkeit

Gottes schlechte Schöpfung

Gute und schlechte Folien