Kolumne

Eclipse Insights: Code-Qualität erhöhen mit Checkstyle

Maximilian Kögel, Jonas Helming

(c)  Shutterstock / Fernando Batista

Wie in den bisherigen Beiträgen dieser Reihe beschrieben, stellen wir ein Eclipse-Oomph-Profil mit unseren bevorzugten Einstellungen und Plug-ins zur Verfügung. Mit Oomph kann sich jeder diese Version von Eclipse mit nur einem Klick installieren. Mehr Informationen dazu bieten die vorherigen Teile der Kolumne.

Wie versprochen beschreiben wir unsere Anpassungen am Eclipse-Standard-Paket nun genauer. Im vorherigen Teil der Kolumne haben wir damit begonnen, die zusätzlichen Plug-ins zu präsentieren, die wir verwenden. Zuerst haben wir EclEmma vorgestellt, eines der beliebtesten Plug-ins für Eclipse. Als nächstes ist ein weiterer Evergreen unter den Eclipse-Plug-ins an der Reihe: Eclipse Checkstyle (Eclipse CS), das im Jahr 2007 sogar zum besten Open Source Eclipse-based Developer Tool gekürt wurde. Mit Checkstyle lässt sich überprüfen, ob der eigene Code zuvor festgelegten Standards entspricht. Das Tool ist dabei nicht Eclipse-spezifisch, sondern für so ziemlich jedes Tool zur Java-Entwicklung verfügbar, von NetBeans bis IntelliJ, von Gradle bis Maven. Wir werden uns aber auf die Integration in Eclipse konzentrieren, die Teil unseres Oomph-Profils ist.

entwickler.tutorial - Microservices

Microservices mit Spring Boot, Spring Cloud und Docker

Eberhard Wolff

In diesem Tutorial wird man auf den Umgang mit Microservices vorbereitet. Eberhard Wolff erklärt zunächst, was Microservices eigentlich sind und mit welchen Chancen und Herausforderungen die Arbeit mit ihnen verbunden ist. Nachdem die Grundlagen etabliert wurden, erklärt er den Umgang mit der Container-Sofware Docker und den Umgang mit dem Spring Framework, die anhand eines Micoservices-Beispiels in der letzten Lektion noch einmal praktisch angewendet werden.

Statische Code-Analyse ist wohl eines der effizientesten Features moderner Code-Editoren und IDEs. Sie hilft Entwicklern dabei, Bugs schon während der Entwicklung zu erkennen. Die Eclipse IDE stellt selbst schon umfangreiche Möglichkeiten zur Überprüfung des Codes zur Verfügung, zum Beispiel zur Markierung nicht instanziierter Variablen oder unsicherer Casts. Beim Schreiben von Code ist das Fehlen von Bugs aber nur ein Teil der Aufgabe. Da Code häufig über Jahre hinweg verwendet und gepflegt wird, ist auch die Verständlichkeit entscheidend. Bei der Arbeit an einem Framework ist das sogar noch wichtiger, weil sowohl die Mitarbeiter als auch diejenigen, die damit später arbeiten, die APIs und Implementierungen verstehen müssen. Verständlichen Code zu schreiben, liegt daher in der Verantwortung jedes Entwicklers.

Tools können dabei sehr hilfreich sein. Bei der Arbeit an Projekten ist es sinnvoll, sich auf bestimmte Regeln zu einigen, die definieren, wie verständlicher Code auszusehen hat. Zum Beispiel kann festgelegt werden, dass Public Methods dokumentiert werden sollten oder Methoden, die eine bestimmte Länge überschreiten, in Sub-Methoden unterteilt werden. Die Einhaltung dieser Art von Regeln kann dann automatisch kontrolliert werden und somit einen Leitfaden für Entwickler darstellen, um die Lesbarkeit zu erhöhen. Genau dabei hilft Checkstyle, in unserem Oomph-Profile ist es vorinstalliert.

Um Checkstyle für ein Projekt zu verwenden, klicken Sie mit der rechten Maustaste in Ihre Eclipse IDE, dort dann auf “Properties”, wählen “Checkstyle” aus und aktivieren es.

image05

Jetzt wählen Sie eine Checkstyle-Konfiguration für Ihr Projekt aus. Dadurch legen Sie die Regeln fest, anhand derer Ihr Code gecheckt wird. Checkstyle bringt bereits einige vorkonfigurierte Optionen mit. Neue Konfigurationen können in den allgemeinen Einstellungen von Checkstyle (Menu “Window” => “Preferences” => “Checkstyle”) hinzugefügt werden. Dort können Sie auch eine Standard-Konfiguration festlegen. Konfigurationen können und sollten innerhalb eines Projekts geteilt werden. Dazu fügen Sie eine Konfiguration hinzu und spezifizieren deren Ort. Das kann entweder eine Remote Location (beispielsweise ein Webserver) oder ein lokaler Ort relativ zum Projekt-Ordner sein. Um offline arbeiten zu können, bevorzugen wir die zweite Option und teilen die Konfiguration über ein gesondertes Projekt im Git Repository.

Um eine Konfiguration anzupassen, klicken Sie auf “Configure”. Das öffnet einen Dialog, über den die anzuwendenden Regeln ausgewählt und eingestellt werden können. Eine detaillierte Beschreibung der möglichen Personalisierungen kann hier eingesehen werden.

 

image04

Sobald Checkstyle für ein Projekt aktiv ist, werden nach einem Rebuild zusätzliche Warnungen angezeigt, falls der Code nicht mit den eingestellten Regeln übereinstimmt. Wenn beispielsweise angegeben wurde, dass Public Methods dokumentiert werden müssen, würde das so aussehen:

image021

Checkstyle bietet außerdem zwei Möglichkeiten an, um einen Überblick über alle Verstöße im Code zu bekommen: eine grafische und eine tabellarische. Diese können über “Window” => “Show View” => Category “Checkstyle” geöffnet werden. Außerdem handelt es sich bei den Warnungen von Checkstyle um “reguläre” Warnungen, sodass sie auch in der Eclipse “Problems View” erscheinen.

Da es eine unüberschaubare Anzahl an möglichen Checks und Konfigurationen gibt, empfehlen wir die folgenden Richtlinien:

  1. Fangen Sie mit einer vorgegebenen Konfiguration an

Bevor Sie das Rad neu erfinden, werfen Sie einen Blick auf bereits vorliegende Konfigurationen. Es stehen einige mitgelieferte Konfigurationen zur Wahl, alternativ können Sie aber auch die Konfigurationen von verschiedenen Open-Source-Projekten verwenden. Werfen Sie einen Blick auf die Einstellungen und sehen Sie sich an, was andere Nutzer gemacht haben. Einiges ist einleuchtend, anderes wird eher zu Diskussionen führen, weil es dazu verschiedene Sichtweisen geben kann. Darum:

  1. Begutachten Sie die Konfiguration und tauschen Sie sich drüber aus

Eine Checkstyle-Konfiguration wird den Stil Ihres Codes beeinflussten, so lange Sie sie verwenden. Je später Sie sie einführen, desto größer wird der notwendige Aufwand zur Anpassung vorhandenen Codes an den eingestellten Standard. Aus diesem Grund werden Konfigurationen meist über eine lange Zeit hinweg unverändert benutzt. Darum ist es wichtig, Konfigurationen vor ihrer Verwendung gründlich zu begutachten und mit dem Team darüber zu sprechen. Das benötigt initial etwas Zeit. Eine Konfiguration, die keinem Teammitglied gefällt, führt aber nur dazu, dass die Entwickler sie ignorieren oder Wege darum herum finden.

  1. Den vorhandenen Code überprüfen

Normalerweise werden Sie bereits Code vorliegen haben. Wenn Sie sich für eine Konfiguration entscheiden, wenden Sie sie am besten auf diesen an und schauen sich die ausgegebenen Warnungen an. Wenn viele Warnungen angezeigt werden, bedeutet das, dass die Konfiguration nicht dem aktuellen Code-Stil der Entwickler entspricht. Dann gibt es zwei Möglichkeiten: Die Warnungen können über einen expliziten Task abgearbeitet werden. Dafür sollten Sie gezielt Zeit einplanen. Alternativ können Sie auch den Check deaktivieren, der die Warnungen produziert. In diesem Fall belassen Sie es dabei, bis Sie genug Zeit haben, sich wirklich darum zu kümmern. Warnungen zu reparieren braucht Zeit, das passiert nicht von selbst und kann nicht mal eben neben der normalen Entwicklung erledigt werden. Wenn ein bestimmter Check bereits 100 Warnungen ausgegeben hat, hält sich auch niemand an die Regel, auch nicht bei neuem Code. Darum empfehlen wir in diesem Fall:

  1. Einen Null-Warnungen-Kurs verfolgen

Ein typisches Problem mit statischen Code-Analyse-Tools wie Checkstyle ist, dass sich niemand um die resultierenden Warnungen kümmert und deren Zahl somit immer größer wird. Ein Grund dafür ist, dass bei der Modifikation existierenden Codes, der bereits Warnungen enthält, kein gesonderter Marker für neue Warnungen existiert. Dadurch gewöhnen sich Entwickler an den Anblick von Warnungs-Markern in allen Projekten. Darum empfehlen wir, einen Null-Warnungen-Kurs zu verfolgen. Wenn das Projekt keine Warnungen enthält, bemerken Entwickler das Auftauchen neuer Warnungen.

Wir müssen zugeben, dass die letzte Empfehlung am schwierigsten zu befolgen ist. Das ist vor allem in laufenden Projekten mit vielen Warnungen der Fall. Der Tipp kann allerdings zumindest für neue Bundles und Projekte umgesetzt werden. Eine Zwischenlösung könnte darin bestehen, die Einführung neuer Warnungen nicht zu erlauben. Das sollte auch getan werden, wenn einem Null-Warnungen-Kurs gefolgt wird. Da Checkstyle in automatische Builds eingefügt werden kann, können diese bei der Erstellung geprüft werden. Für uns funktioniert die Lösung am Besten, den Build fehlschlagen zu lassen, wenn neue Warnungen auftauchen. Das funktioniert insbesondere perfekt in Kombination mit Gerrit.

Bei der Integration in Builds ist es außerdem möglich, Statistiken über die Zahl und Art von Warnungen im Projekt zu erstellen. Unserer Erfahrung nach sind diese Zahlen aber nutzlos, wenn es keine klaren Ziele gibt, die auch durchgesetzt werden.

Am Ende ist Checkstyle nicht mehr oder weniger als ein Tool, mit dem sich überprüfen lässt, ob Code einem bestimmten Regelset entspricht. Es ist vergleichbar mit einer Rechtschreibprüfung in einer Textverarbeitung. Es überprüft weder, ob der Code sinnvoll ist, noch dessen Qualität. Dafür sind Code Reviews, beispielsweise mit Gerrit, viel besser geeignet.

Auch wenn die Möglichkeiten des Tools eingeschränkt sind, ist es immer noch eine gute und wertvolle Ergänzung zu den statischen Checks, die in Eclipse integriert sind. Richtig angewendet hilft es definitiv dabei, geschriebenen Code zu standardisieren und die Verständlichkeit zu erhöhen. Darum hat Checklist sich seinen Platz in unserem EclipseSource-Oomph-Profile definitiv verdient.

Wenn Sie andere tolle Tools wie dieses kennen, können Sie sie natürlich auch ihrer IDE hinzufügen und so das Oomph-Profil erweitern. Wenn Sie glauben, dass ein bestimmtes Plug-in interessant für die Mehrheit der Nutzer sein könnte, setzen Sie sich bitte mit uns in Verbindung, sodass wir überprüfen können, ob wir es ins allgemeine Profil aufnehmen.

Probleme können Sie uns über unser GitHub-Projekt mitteilen.

Im nächsten Teil unserer Kolumne werden wir weitere Plug-ins beschreiben, die wir unserem Oomph Profil hinzugefügt haben.

Bis dahin, viel Spaß mit unserem EclipseSource-Oomph-Profile!

Geschrieben von
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: