Statische Code-Analyse mit dem PHP Code Sniffer

von Nils Langner am 9. März 2009

Lesetipps

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.

Nils Langner

Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

Zum Profil von Nils Langner

19 Kommentare »

chris
am 9. März 2009 um 08:59 Uhr

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!
Malte
am 9. März 2009 um 10:46 Uhr

Codesniffer ist super
Carsten
am 9. März 2009 um 11:14 Uhr

Mich würde interessieren, ob man den auch irgendwo ohne das PEAR-Gedöns benutzen kann?
Nils
am 9. März 2009 um 13:36 Uhr

@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.
admin
am 9. März 2009 um 13:41 Uhr

@Carsten: Schau mal hier http://download.pear.php.net/package/PHP_CodeSniffer-1.2.0RC1.tgz da kannst du das Archiv runterladen.
Michael
am 9. März 2009 um 17:48 Uhr

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!
Miss Rootix
am 9. März 2009 um 20:55 Uhr

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.
Nils Langner
am 9. März 2009 um 21:01 Uhr

@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.
PHP hates me - Der PHP Blog » PHP Code Sniffer - Installation und Verwendung
am 10. März 2009 um 08:36 Uhr

[...] gestern schon erwähnt, soll der heute Beitrag der Installation und der rudimentären Verwendung des PHP [...]
Ralf
am 10. März 2009 um 17:30 Uhr

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
admin
am 10. März 2009 um 17:47 Uhr

@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”.
uli
am 12. März 2009 um 17:07 Uhr

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!
admin
am 12. März 2009 um 20:25 Uhr

@uli: danke, danke. aber das gehört ja schon fast dazu haben sich doch so einige dran gewöhnt zu haben
PHP hates me - Der PHP Blog » Projektwerkstatt: Authors AdSense
am 17. März 2009 um 08:00 Uhr

[...] die letzte Woche sehr PHP Code Sniffer lastig war, will ich heute mal wieder eine meiner Ideen preisgeben. Wie schon öfters handelt es [...]
Blog der Woche „PHP hates me“: „Als ich angefangen habe, gab es kaum gute deutschsprachige PHP-Blogs“ » t3n Magazin
am 23. März 2009 um 10:39 Uhr

[...] Lesern jede Menge Spaß gebracht. Meine liebsten „ernsten“ Artikel sind die der Reihe über die statische Code-Analyse, da ich hier selbst viel gelernt [...]
Codemetriken in PHP « What was it again?
am 19. Mai 2009 um 09:07 Uhr

[...] Statische Code-Analyse mit dem PHP Code Sniffer [...]
Parameter verändern | PHP hates me - Der PHP Blog
am 11. Juni 2009 um 07:23 Uhr

[...] hat, dann stabilisiert man seine Programme auf diese Weise. Wer also Ahnung im Umgang mit dem PHP_CodeSniffer hat, der sollte mal eine Regel schreiben, die so etwas [...]
Die PHP_CodeSniffer Odyssee | PHP hates me - Der PHP Blog
am 28. August 2009 um 07:50 Uhr

[...] der PHP_CodeSniffer für ein Tool ist, solltet ihr nach meiner Sniffer Woche ja alle wissen. Ich wollte mal wieder einen Sniff schreiben. Einen Sniff, der nach Variablen sucht, [...]
Volker Dusch
am 8. März 2010 um 11:29 Uhr

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