Arndt's Blog

Werkzeuge zur Erhaltung der Softwarearchitektur – Checkstyle – Teil 9

Checkstyle

In diesem und den kommenden Posts stelle ich die “magischen drei” im Bereich der statischen Code-Analyse vor.

  • Checkstyle
  • PMD
  • Findbugs

Ohne diese Werkzeuge mit geeigneten Regelwerken sollte keine Entwicklungsarbeit mehr erfolgen. Sie sind die Basis für die dauerhafte Einhaltung der Architekturvorgaben und ebenso die Basis für die Vermeidung technischer Schulden. Die einzelnen Werkzeuge kann man inhaltlich nicht klar von einander abgrenzen, da sie größere Schnittmengen haben. Jedes Tool hat seine Stärken in einem anderen Bereich, deckt aber auch vieles anderes ab. Erst die Kombination alle Tools ergibt ein gutes Grundniveau.

Checkstyle ist besonders stark im Bereich der Einhaltung der Kodierungsrichtlinien. Es schafft somit die Basis für das Verstehen von Code, das wie früher schon erwähnt häufig deutlich mehr als 50% unserer Arbeit ausmacht.

Was wird analysiert?

Checkstyle analysiert den Quellcodes des Projekts – also keinen Bytecode.

Besonderheiten

  • Code-Konsistenz / Struktur / Codestyle
  • Dokumentation (Javadoc)
  • in Teilen Komplexität

Integration

  • IDE
  • In die Übernahme in SVN/Git durch die Verwendung von Pre-Commit Hooks
  • Maven-Build (Ausführung und Erzeugen von Basisdaten)
  • Jenkins (GUI und Grenze für ungültige Artefakte)

False Positive Behandlung

  • Parametrisierung bzw. Reduzierung der verwendeten Regeln
  • Codestellen ignorieren: über Annotationen oder einen Kommentar; Konfiguration im SuppressionFilter
  • Ausschluss von Paketen bei der Prüfung: insbesondere auch bei der Verwendung von Pre-Commit Hooks

Regelerweiterung

Die Erweiterung der Regeln ist aus meiner Sicht hier und bei den anderen Werkzeugen lange Zeit nicht notwendig, da die Basisregeln eine gute Basis bieten. Sind alle diese Regeln erfüllt, ist das Projekt im Bereich QS schon einen weiten Weg gegangen. Anpassungen sind möglich über

  • Java
  • http://checkstyle.sourceforge.net/writingchecks.htm

Beispielkonfiguration

Das folgende Beispiel zeigt eine Whitelist – also eine Beschreibung der Regeln, die angewendet werden sollen.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" 
  "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">
    <property name="severity" value="warning" />
    <property name="localeCountry" value="DE" />
    <property name="localeLanguage" value="de" />

    <module name="JavadocPackage">
        <property name="allowLegacy" value="true" />
    </module>
    <module name="TreeWalker">
        <!-- Klassen und Importe -->
        <module name="AbstractClassName">
            <property name="format" value="^Abstract.*$" />
        </module>
        <module name="AvoidStarImport" />
        <module name="PackageName" />
        <module name="RedundantImport" />
...
    </module>
</module>

Pre-Commit Hook

Ein Pre-Commit Hook ist ein Python oder Shell Skript, das vor dem Einchecken auf dem Server ausgeführt wird. In diesem wird das Change Set im SCM ermittelt und auf diesem Checkstyle mit einem geeigneten Regelwerk angewendet. Sind Regeln nicht erfüllt, wird die Übernahme in das SCM System mit einer entsprechenden Fehlermeldung verweigert.

Auf diese Weise bekommt der Entwickler sehr schnelles Feedback und es wird “schlechter” Code gar nicht erst in das SCM aufgenommen

Du hast Fragen oder Anmerkungen? Kontakt: arndt@schoenb.de

arndt