Gute Qualität in JavaScript mit Jenkins und PHPStorm/WebStorm
Kommentare

jslint
Ein sehr weit verbreitetes Werkzeug zur Qualitätssicherung in JavaScript ist JSLint [2]. JSLint parst den übergebenen JavaScript-Quelltext und prüft ihn auf Syntaxfehler und bekannte Antipatterns

jslint

Ein sehr weit verbreitetes Werkzeug zur Qualitätssicherung in JavaScript ist JSLint [2]. JSLint parst den übergebenen JavaScript-Quelltext und prüft ihn auf Syntaxfehler und bekannte Antipatterns in der Entwicklung. Das Werkzeug wurde von Douglas Crockford entwickelt und stellt ein Hilfsmittel dar, die Empfehlungen korrekt umzusetzen, die er in seinem Buch „JavaScript: The good parts“ beschreibt und näher erläutert. Das Ziel liegt dabei darin, dass die Vorteile von JavaScript als Programmiersprache voll ausgenutzt werden sollen und die, teils auch historisch gewachsenen, Nachteile möglichst vermieden werden sollen. Einige Beispiele für Warnungen von JSLint sind die Verwendung von eval, inkrement– und dekrement-Operatoren oder continue.

Für die Verwendung von JSLint in PHPStorm muss kein zusätzliches Plug-in installiert werden. JSLint ist standardmäßig ein fester Bestandteil der IDE. Diese bietet in der Konfiguration unter dem Punkt JAVASCRIPT | CODE QUALITY TOOLS die Option JSLINT. Hier kann das Werkzeug für das Projekt aktiviert oder deaktiviert werden. Außerdem steht dem Entwickler die Möglichkeit zur Verfügung, JSLint hier zu konfigurieren und festzulegen, welche Warnungen ignoriert werden sollen.

Um JSLint in Jenkins einzubinden, wird die Kommandozeilenversion des Werkzeugs benötigt. Es kann beispielsweise „jslint4java“ verwendet werden. Dieses Tool liegt als .jar-Datei vor, die idealerweise im Suchpfad des Jenkins-Nutzers liegen sollte. Dann kann JSLint mit einer einfachen Kommandozeile eingebunden werden. Hierfür wählt man über den Button ADD BUILD STEP den Punkt EXECUTE SHELL und trägt dann die folgende Kommandozeile ein:

java -jar jslint4java.jar -report xml /path/to/src/*.js > jslint.xml

Dieser Befehl sorgt dafür, dass sämtliche Dateien im angegebenen Verzeichnis, die auf .js enden, mit JSLint geprüft werden. Die Ausgabe erfolgt im XML-Format, was die spätere Darstellung in Jenkins erleichtert. Als Letztes wird die Ausgabe in eine Datei umgeleitet. Die Angaben von Dateien in Jenkins beziehen sich immer auf den aktuellen Workspace. Das bedeutet, dass sich ein Entwickler keine Gedanken über absolute Pfade oder Konflikte mit anderen Projekten machen muss. Die angegebenen Dateien liegen in einem Verzeichnis, das exklusiv für das aktuelle Projekt verwendet wird. Sowohl die Build Steps als auch die spätere Visualisierung beziehen sich auf diesen Workspace.

Zur Anzeige der von JSLint gefundenen Fehler kann das Jenkins Violations Plugin verwendet werden. Dieses Plug-in erwartet eine standardisierte XML-Datei als Eingabe und deckt damit nicht nur ein einzelnes Tool wie JSLint, sondern eine ganze Reihe von Analysetools ab. Hierunter fallen unter anderem Programme wie beispielsweise checkstyle, PHPCS oder pmd [3].

Der Report über die Violations ist innerhalb des Projekts unter dem Punkt VIOLATIONS verfügbar. Hier kann man verschiedene Informationen abrufen wie den Typ und die Anzahl der Violations oder die Anzahl der Dateien mit Violations. Außerdem steht dem Betrachter eine Grafik über die Entwicklung der Anzahl der Violations über alle Builds zur Verfügung.

JSLint deckt allerdings nur einen Teil der statischen Codeanalyse ab. Hier wird vor allem auf syntaktische Korrektheit und bekannte Antipatterns geprüft. Ein anderer Bereich der statischen Codeanalyse ist das Aufspüren von mehrfach vorkommenden Codeblöcken, mit dem sich der folgende Abschnitt befasst.

Copy/Paste Detector

In der Programmierung ist es kurzfristig oft einfacher, existierende Codestellen, die an anderer Stelle ebenfalls benötigt werden, einfach zu kopieren, anstatt sie sauber herauszulösen und an mehreren Stellen wiederzuverwenden. Der Einsatz von so genanntem „Copy and Paste“ wirkt sich mittel- bis langfristig negativ auf die Software aus und macht die anfängliche Zeitersparnis schnell zunichte, da die Wartbarkeit der Software stark eingeschränkt wird. Ein anderes Problem im Zusammenhang mit dupliziertem Code kennen die meisten Softwareentwickler wahrscheinlich aus dem täglichen Leben: Ein Fehler ist behoben, einige Zeit später beschwert sich der Kunde, dass der angeblich bereits behobene Fehler erneut auftritt. Eine kurze Recherche im Quellcode ergibt, dass der Bugfix immer noch im Quellcode vorhanden ist. Erst nach einer weiteren Analyse stößt man darauf, dass der fehlerhafte Code auch noch an anderen Stellen in der Software verwendet und dort bisher noch nicht behoben wurde. Hier erleichtern es verschiedene Werkzeuge dem Entwickler, duplizierte Codestellen zu identifizieren und im Anschluss zu extrahieren und zu verallgemeinern.

In PHPStorm ist die Unterstützung zur Suche nach dupliziertem Code fester Bestandteil der Anwendung. Über das CODE-Menü erreicht man den Punkt LOCATE DUPLICATES…. Hier kann man aus verschiedenen Optionen wählen, um den Suchradius einzuschränken. Es empfiehlt sich allerdings, in regelmäßigen Abständen das gesamte Projekt zu durchsuchen. Nachdem der Bereich festgelegt wurde, in dem gesucht wird, muss festgelegt werden, in welchen Sprachen nach dupliziertem Code gesucht werden soll, in unserem Fall ist das „JavaScript“. Als Nächstes kann man festlegen, wie mit Variablen, Funktionen und Literalen umgegangen werden soll, beziehungsweise ob sie anonymisiert werden sollen. Eine Anonymisierung führt dazu, dass sich das Tool nicht durch unterschiedlich benannte Variablen oder Funktionen überlisten lässt. Zu guter Letzt muss noch ein Schwellwert festgelegt werden, ab dem Quellcode als Duplikat angesehen wird. Je nach Projektgröße und -struktur muss hier ein sinnvoller Wert gefunden werden, damit nicht im ersten Schritt schon zu viele Duplikate gefunden werden. Es empfiehlt sich hier ein iterativer Ansatz, bei dem der Grenzwert schrittweise verschärft wird. Außerdem sollte Quellcode, der vom Entwickler nicht direkt beeinflusst werden kann, wie beispielsweise Bibliotheken wie jQuery oder Ähnliches nicht geprüft werden, da dies zu unnötigen Meldungen führen kann. Die gefundenen Stellen werden in einem separaten Toolfenster angezeigt. Die Datei kann dann per Doppelklick in den Editor geladen werden und das Duplikat aufgelöst werden.

Die Integration in Jenkins gestaltet sich ähnlich wie schon die von JSLint. Es muss lediglich ein weiterer „Build Step“ hinzugefügt werden:

/opt/PMD/bin/run.sh cpd --minimum-tokens 12 --files /path/to/src
--language ecmascript --format xml > cpd.xml

Als Basisplattform für die Copy/Paste Detection dient PMD. Dieses Werkzeug stammt ursprünglich aus der Java-Welt und dient dort zum Auffinden potenzieller Fehler, ungenutztem Code oder komplizierten Ausdrücken. PMD wurde über die Zeit immer weiter entwickelt und dabei wurden weitere Sprachen wie beispielsweise JavaScript integriert.

Wichtig an dieser Kommandozeile ist die Anzahl der Tokens, die geprüft werden, also einzelne logische Einheiten der Sprache. Hier muss ein vernünftiges Maß gefunden werden, damit nicht zu viele Duplikate gefunden werden. Die Option language gibt an, dass Dateien im ECMAScript-Standard geprüft werden sollen. Das Ausgabeformat ist XML und wird in eine entsprechende Datei umgeleitet.

Sowohl JSLint als auch die Copy/Paste Detection fallen in die Kategorie der statischen Codeanalyse. Der Quellcode wird dabei direkt analysiert, die Anwendung muss dazu nicht ausgeführt werden. Ein anderes Gebiet sind Softwaretests. Hier wird die Software ausgeführt und ihre Teile werden auf deren Funktionsfähigkeit geprüft.


Themen der letzten Seite:

  • Unit Tests
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -