Das Code-Review Tool PMD [1] kann als starker Partner an der Seite eines Programmierers eingesetzt werden. Natürlich versucht der Entwickler immer konzentriert alles richtig zu machen und keine Fehler einzubauen – leider gelingt es aber nicht immer, fehlerfreien Code zu schreiben. Hier kommen kleine Helfer wie PMD zum Einsatz, die den Entwickler unterstützen, indem sie nach typischen Fehlermustern suchen.
PMD durchsucht anders als andere Tools den Source-Code (nicht die compilierten Klassen) nach potenziellen Gefahrenquellen. Ein Beispiel ist das Muster des “MissingBreakInSwitch” – Es wird darauf hingewiesen, dass in einem case Zweig einer Switch-Anweisung kein break zu finden ist.
Die Regeln unterstützen neben dem Auffinden von Bugs, auch das Einhalten von OO-Prinzipien. Als Beispiel sei “LooseCoupling” genannt: es wird gefordert, mit Interfaces (wie List) und nicht mit Implementation (wie ArrayList) zu arbeiten.
Ein weiterer Punkt, in dem PMD dem Entwickler unter die Arme greift, ist die Lesbarkeit des Codes:
“ConfusingTernary” – in einem If-Audruck sollte der Testausdruck nicht negiert sein, da dies die Lesbarkeit mindert, wenn noch ein else folgt, z.B.:
if (!list.isEmpty()) { this.doSomething(); } else { this.doSomethingElse(); } |
läßt sich nicht so fließend lesen wie
if (list.isEmpty()) { this.doSomethingElse(); } else { this.doSomething(); } |
PMD kann individuell verschieden genutzt werden – einerseits als Tool, was immer mal wieder während der Implementation ausgeführt wird, andererseits kann es auch fest in einen Buildprozess integriert werden (z.B. Ant, Maven), um Fehlerquellen zu reporten oder sogar um den Build scheitern zu lassen.
Letzteres kann durch das Anpassen der Fehlerpriorität erreicht werden, so dass das Nicht-Einhalten einer Regel quasi zu einem Compilerfehler führt.
Ebenfalls lässt sich PMD in der Auswahl der zu prüfenden Regeln an die eigenen Bedürfnisse anpassen – so ist es z.B. nicht notwendig gegen J2EE Regeln prüfen zu lassen, wenn diese nicht relevant bzw. sogar störend für das aktuelle Projekt sind.
Für eine manuelle Prüfung des Codes bietet sich das Eclipse-Plugin [2] an. Hiermit können selbstgewählte “Pakete” durchsucht werden – ganze Projekte bis hin zu einzelnen Klassen.
Eclipse-Plugin
Nach der Installation des Eclipse-Plugins [2] kann es wie gewohnt über Window ->Preferences -> PMD für den gelegentlichen Einsatz konfiguriert werden.
Wie oben schon erwähnt, lassen sich die anzuwendenden Regeln einzeln auswählen und die Prioritäten auf die verschiedenen Bedürfnisse anpassen.
Sehr hilfreich für eine firmenweite Verteilung ist die Ex- und Import-Funktion. Hierüber können beispielsweise die von PMD bereitgestellten RuleSets geladen und dann als eigener Satz exportiert werden.
Zum Einsatz bringen kann man PMD über das Context-Menü der verschiedenen Resourcen – Projekt, Package, Klasse – durch die Auswahl von PMD -> Check Code With PMD. Eine Auswertung findet dann in einem Extra Tab statt, in dem die gefundenen potentiellen Fehler z.B. nach Priorität und Klasse aufgelistet werden. Zu den Regelverstößen ist auch eine Beschreibung verfügbar, die teilweise Hinweise gibt, wie das “Problem” zu lösen ist.
Weiteres
Für PMD können auch neue Regeln erstellt bzw. die existierenden modifiziert werden – es sei auf [1] verwiesen.
Neben PMD gibt es diverse weitere Code-Review Tools (z.B. FindBugs), die einem die “Käfer” vom Leib halten helfen.
[1] http://pmd.sourceforge.net/
[2] http://pmd.sf.net/eclipse
