Kategorien
Statische Code-Analyse mit dem PHP Code Sniffer
Mit dem heutigen Tage wollen wir eine neue Kategorie einführen. OK eigentlich ist es keine feste Kategorie, vielmehr eine neue Struktur. Ich hatte mich ja vor kurzem darüber ausgelassen, dass ich es schade finde, dass ich bei sieben Artikeln in sieben nicht die Qualität pro Artikel erreichen kann, die ich gerne hätte. Aus diesem Grund will ich mich jetzt eine ganze Woche lang nur um ein Thema kümmern. Ein paar Wochenthemen sind mir auch schon spontan eingefallen. Da wären statische Code-Analyse mit dem PHP-Code-Sniffer (mit dem wir auch anfangen wollen), Unit Testing, Software Metriken und Continuous Integration. Ich denke, dass alle vier Themen sehr spannend auf ihre Art sind und euch mit Sicherheit gefallen werden. Aber das werden wir ja sehen.
Diese Wochen wollen wir also mit der statischen Code-Analyse füllen. Dabei werden wir die fünf Tage wie folgt einteilen:
- Statische Code-Analyse, was ist das?
- PHP-Code-Sniffer installieren und verwenden
- Regelsets zusammenstellen
- Eigene Regeln erstellen
- Einbinden der Regeln in PhpUnderControl bzw. Ant
Ich hoffe, dass ich euch damit eine Woche bei der Stange halten kann, aber ich denke schon. Meistens lag ich ja richtig mit meinem Fokus. Aber fangen wir einfach mal an.
Statische Code-Analyse
Die statische Code-Analyse ist in den meisten objektorientierten Programmiersprachen gang und gebe. Sie wird verwendet um mit wenig Wartungsaufwand eine hohe Quellcode Qualität zu erreichen. Dabei wird eine Analyse auf den existierenden Code gefahren und zum Beispiel Verstöße gegen die vorher definierten Programmierrichtlinien gemeldet. Es können aber auch Metriken über das Projekt berechnet werden. Wichtig dabei ist, dass der Input immer der Code selbst ist. Hierbei geht es auch nicht Performance Messungen oder ähnlichem, denn die Analyse selbst findet auf dem Code und nicht auf der Ausführung statt.
Wir können also mit Hilfe der Statischen Code-Analyse Probleme, wie nicht initialisierte Variablen, zu lange und komplexe Methoden oder ein einfaches „Konstanten-werden-groß-geschrieben“, finden, ohne selbst aktiv Tests zu schreiben für jede neue Funktionalität.
Der Vorteil liegt also klar auf der Hand. Ich schreibe meine Regeln zum Prüfen auf Verstöße ein einzige Mal und werde diesen Fehler dann in Zukunft immer finden und das auch in frischem Code.
Diese Art zu testen ist leider in PHP die letzten Jahre ein wenig vernachlässigt worden, gewinnt aber immer mehr an Ansehen, was wir nicht zuletzt Sebastian Bergmann und Manuel Pichler zu verdanken haben, die mit phpDepends, PhpUnderControl und PHPUnit mächtige Tools entwickelt haben, die die Berechnung von Metriken und das permanente Testen bzw. Prüfen erst auf einem hohen Niveau möglich gemacht haben.
Eingehen möchte ich aber nicht unbedingt auf diese Helferchen, denn heute wollen wir uns auf ein anderes Tool konzentrieren, dem PHP-Code-Sniffer (PCS). Er hilft uns den Code strukturiert zu analysieren und eigene Regeln zu verfassen, die wir in unseren „Bauvorgang“ einbinden können.
PCS ist Teil der PEAR Komponenten Bibliothek und kann kostenlos verwendet und erweitert werden. Er wurde in und für PHP 5 Code geschrieben. Am häufigsten wird dieses Tool angesetzt, um Coding Standard Verstöße zu finden und zu tracken. Aus diesen Grund bietet der Sniffer bereits einige Standards, wie die des PEAR Projektes oder des Zend Frameworks, nativ an. Regeln wie das Großschreiben von Konstanten oder die maximal Länge einer Methode finden sich aber ebenfalls out-of-the-box wieder.
Vielleicht interessiert es ja den ein oder anderen noch, warum ich dieses kleine Tutorial verfasse. Der erste Grund ist, dass ich die statische Codeanalyse als sehr wichtiges Qualitätssicherungs-Tool betrachte. Der zweite ist noch viel einfacher. Bis jetzt hat sich niemand deutschsprachiges die Mühe gemacht, ein gutes Tutorial zu verfassen und auch im englischsprachigen Raum sieht es eher mau aus. Also habe ich mich einfach erbarmt. Was mir natürlich auch noch sehr an der Thematik gefällt, ist der hohe Kooperationsfaktor. Ich schreibe eine Regel und jeder andere PHP Entwickler weltweit kann diese verwenden, denn die meisten Regeln werden nicht in Abhängigkeit eines Projektes verfasst. Dazu ist mir auch noch eine kleine „Projektwerkstatt“ eingefallen, die ich am Ende der Woche auch noch vorstellen will.
Bevor ich es vergesse, diese einwöchige Reihe ist nur ein Versuch. Bis jetzt habe ich kaum etwas mit dem Code Sniffer selbst gemacht, außer ihn verwendet. Das schreiben von Regeln kann sehr komplex werden, aber ich traue mich trotzdem mal ran. Ich hoffe, dass ich ohne Probleme durch die Woche komme, aber ihr werdet es ja sehen.
Off topic: Ich liebe dieses Blog, sehr oft tauchen neue Artikel auf, meistens sind sie sehr interessant und ausführlich. Was ich besonders mag, die Artikel sind soweit ich das beurteilen kann, immer „Unikate“, denn auf anderen blogs findet man oft ähnliche Artikel oder sogar Artikel mit dem gleichen Inhalt. Hier gibts immer was neues aber keinen Text den man schon woanders gelesen hat. Weiter so! 😉
Codesniffer ist super 😀
Mich würde interessieren, ob man den auch irgendwo ohne das PEAR-Gedöns benutzen kann?
@Malte: So viel, wie du kommentierst, hast du dir mal überlegt vielleicht mal einen Beitrag zu schreiben? Finde deine Kommentare nämlich meistens ziemlich wertvoll.
@Carsten: Schau mal hier http://download.pear.php.net/package/PHP_CodeSniffer-1.2.0RC1.tgz da kannst du das Archiv runterladen.
Ich habe es eben auch ausprobiert (initiiert durch deinen Artikel). Habe mich eigentlich von PEAR gelöst soweit es möglich ist (und versuche, nur ZendFramework Komponenten zu nutzen). Deshalb habe ich auch das Archiv (Link siehe oben) genommen.
Man muß aber noch 1-2 Änderungen manuell vornehmen, und zwar findet man in „phpcs.bat“ und „phpcs“ die „Variable“ @php_bin@, die man noch ersetzen muß, damit man es Standalone nutzen kann.
Und man glaubt es kaum, verglichen mit dem ZendFramework Codestyle habe ich direkt tausende von Meldungen über falsche Klammern und fehlenden Leerzeichen bekommen 😉
@Nils: Weitermachen!
Habe ich es heute mit den Augen, oder klafft da tatsächlich eine Lücke in Form von 2 fehlenden Beiträgen? Da will ich mich doch gleich dem Vorredner anschließen: jetzt bloß nicht schlappmachen!
Den CodeSniffer haben wir bei uns in der Firma übrigens auch laufen, wird regeltechnisch aber zunächst noch an der kurzen Kette gehalten, damit er seine Nase nicht in allzu sehr in Legacy-Code steckt und uns mit (unverschuldeten) Verstößen nervt. Ich bin schon gespannt, welche Regeln du aus dem Hut zaubern wirst.
@Miss Rootix: Ja da gibt es eine Lücke 😉 Habe ich ja mit dem 200sten Eintrag beschlossen, dass es am WE keine Beiträge mehr geben wird. Zumindest bis genügend Co-Autoren da sind, die mitmachen. Aber so wie es zur Zeit aussieht, könnte es gut sein, dass wir „bald“ wieder die Wochenenden füllen.
Was die Regeln angeht, die ich „zaubern“ werde, da sei mal nicht zu erwartungsvoll. Es soll ja nur eine kleine Einführung sein. Da ich aber Spaß dran gefunden habe werde ich jetzt wohl öfters mal was schreiben.
Ich merke schon, Deine Themen gehen genau in die Richtung, in der ich selber noch Nachholbedarf habe. Immer wieder spannend hier vorbeizuschauen. Weiter so, spannende Themen, Ralf
@Ralf: Danke 🙂 Es sind aber auch oft Themen bei denen ich Nachholbedarf hatte und ich mir einfach gedacht habe: „Wenn ich mich schon einlese, dann kann ich auch was zu schreiben“.
ich finde die beiträge auch echt super, was die themen angeht! finde eigentlich nichts zu meckern ausser ne kleinigkeit: am besten noch 1-2 mal korrekturlesen vorm abschicken, nachdem hier und da noch ein paar holprige sätze drin sind.
Sonst: TOP! Weiter so!
@uli: danke, danke. aber das gehört ja schon fast dazu 🙂 haben sich doch so einige dran gewöhnt zu haben 😉
Hach ja, PHP Code Sniffer. Die initiale Hürde anzufangen selber Regeln zu schreiben ist so hoch wie bei keinem anderen QA Tool das mir untergekommen ist. So halbherzig dokumentiert das man lieber gleich google konsultiert (Na gut, das ist n letzer Zeit besser geworden).
Wenn man das geschafft hat bekommt man aber als Belohnung ein (dann) reibungslos funktionierendes Tool das sich wunderbar in PhpUnderControl oder Arbit integriert und hübschen nützlichen Output macht.
Gleich einen schon existierenden Coding-Standard wie PEAR oder ZEND zu benutzen spart hier natürlich (mal wieder) Zeit 😉