Facebook
Twitter
Google+
Kommentare
0
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

PHP Code Sniffer in Ant und PhpUnderControl integrieren

Heute kommen wir auch schon zum letzten Teil unserer ersten einwöchigen Reihe. Nachdem wir jetzt in der Lage sind, eigene Regeln zu erstellen, müssen wir sie nur noch in unseren Bauprozess einbeziehen. Ja ich weiß, PHP ist eine interpretierte Sprache, die Projekte müssen also gar nicht wirklich gebaut werden, so wie vielleicht C++ Programme. Trotzdem sollte es einen Bauprozess geben, in dem noch mal alle Codeteile geprüft werden.

Verfolgt man den Continuous Integration Ansatz, so sollte man sein Projekt bauen, so oft es geht oder vielleicht besser: so oft es Sinn macht. Sobald ein Teammitglied in der Versionsverwaltung Änderungen eingecheckt hat, so sollte der Bau getriggert werden. Und genau dies übernimmt PhpUnderControl (phpuc) für uns. Wie man genau diesen Cruise Control Aufsatz konfiguriert, möchte ich zu einem späteren Zeitpunkt darauf eingehen, heute geht es nur darum, wie ich meine Ant Skripte so anpasse, dass meine Sniffs bei jedem Durchlauf mit angeschmissen werden.

Da phpuc, genau wie Cruise Control, auf Ant Skripte setzt, werde ich einfach mal kurz erläutern, welche Zeilen man einfügen muss, um vollen Code Sniffer Support zu erlangen. Ich muss dazusagen, dass, soweit ich das in Erinnerung habe,  phpuc die Einträge schon vorbeireitet, falls man sein Projekt mit den mitgelieferten Tools erstellt. Nichtsdestotrotz will ich heute auf die Konfiguration eingehen. Diese befindet es sich, wie bei ant üblich in der build.xml Datei.

<target name="php-codesniffer">
  <exec executable="phpcs" dir="${basedir}" output="${basedir}/build/logs/checkstyle.xml">
    <arg line="-d max_execution_time=-1 -d memory_limit=-1 --tab-width=0
               --standard=PhpHatesMe
               --report=checkstyle
               --extensions=php
                source/"/>
  </exec>
</target>

Sieht irgendwie ziemlich kompliziert aus, ist es aber eigentlich gar nicht. Das target definiert einfach nur eine ausführbare Aktion, die ich mit ant aufrufen kann (ant php-codesniffer). Im exec Teil führen wir die Programme auf, die wir nach und nach aufgerufen werden, das arg Element die Argumente zum dazugehörigen Programm. So einfach. Vielleicht noch eine Kleinigkeit zum output Parameter: dieser definiert die Datei, in die der Konsolen-Output des Code Sniffers „hingepiped“ wird.

Die Einstellungen, wie ich sie aufgeführt habe, sind allesamt kompatibel mit PhpUnderControl.

Projekt aufteilen

Ein Tipp, den ich noch mitgeben will, ist die Aufteilung des Projektes, das untersucht werden soll in zwei Teile. Der eine Teil ist neuer Code und der andere Legacy, also alter Code. Aber gehen wir erstmal drauf ein, warum dies wichtig sein kann. Ich gehe mal davon aus, dass die meisten Projekte bereits existieren, in die man den Code Sniffer einführen will. Hier gibt es also das Problem, dass man viel Code hat, der sich an keine Regeln hält, da diese erst einige Zeit nach dem Code verpflichtend wurden, zumindest ist das meine Erfahrung. Was macht man also mit dem alten Code? Das schönste wäre es, wenn wir die Regeln nur über neuen Code laufen lassen könnten. Leider gibt es da bis jetzt noch kein Tool, das dies bewerkstelligen könnte (ich bin dabei eins zu schreiben), also müssen wir händisch unterscheiden. Wir haben also Komponenten, die den verschäften Regeln standhalten müssen, aber genauso gut alten Code, der vielleicht nur ein paar einfachen Regeln genügen muss. Aus diesem Grund brauchen wir zwei Standards (neu und alt)., denn was hilft einen die besten Sniffs, wenn es auf einmal tausende von Verletzungen gibt, die eh niemals jemand beheben will. Man sollte immer versuchen ein sauberes System zu haben und wenn dies heißt, nicht von Anfang an alle Regeln anzuschalten, dann sei es eben so. Nach und nach sollte man aber alte Komponenten zu den verschäften Regeln hinzuzufügen oder man schaltet nach und nach vereinzelt neue Regeln zum kompletten Projekt hinzu. Was hier in der Praxis bessere Werte liefert ist von Projekt zu Projekt unterschiedlich und kann nicht pauschal beantwortet werden. Ich finde beide Ansätze legitim.

Fazit

Die Woche ist schon wieder rum und wir sind mit unserer ersten Serie am Ende. Falls es euch gefallen hat, dann seit so nett und setzt einen Link, falls ihr kein Fan seit, dann setzt ein Link mit irgendwas fiesen. Ich hoffe, dass ihr diese Woche genau so viel mitgenommen habt, wie ich auch. Vielleicht habe ich ja Interesse an mehr geweckt und den ein oder anderen dazu gebracht seine Projekte besser zu testen.

Da ich in der nächsten Zeit wohl noch einiges mit dem PHP Code Sniffer anstellen will, könnt ihr euch darauf gefasst machen, dass dies nicht der letzte Beitrag zu diesem Thema war.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen