Facebook
Twitter
Google+
Kommentare
21

PHP Code Sniffer – Installation und Verwendung

Wie gestern schon erwähnt, soll der heute Beitrag der Installation und der rudimentären Verwendung des PHP Code Sniffers gewidmet werden. Ich gehe mal davon aus, dass die meisten von euch einen Linux Server verwenden, auf dem ihre PHP Anwendung läuft, aus diesem Grund werde ich auch „nur“ die Installation unter Linux erläutern.

Installation

Wie ihr ja bereits wisst, ist PCS Teil der PEAR Komponenten Bibliothek und kann deshalb auch ganz einfach unter Verwendung des PEAR Installers auf dem System installiert werden.

pear install PHP_CodeSniffer-1.2.0a1

Da die Version 1.2.0a1 zum Zeitpunkt, als ich dieses Tutorial erstellt habe die aktuellste war kann es natürlich sein, dass ihr zu einem späteren Zeitpunkt eine andere Version bevorzugen solltet. Für alle, die kein PEAR auf ihrem System installiert haben, die können dies ganz einfach, falls apt-get vorhanden, mit den folgenden Zeilen ändern:

apt-get install php-pear

Eigentlich sollte jetzt der Verwendung des Sniffers nichts mehr im Wege stehen. Ein Aufruf von phpcs sollte jetzt das Kommandozeilen Tool, das übrigens komplett in PHP geschrieben wurde, starten und die möglichen Optionen anzeigen. Bevor ihr die installieren Dateien suchen müsst, hier der Pfad, in dem PEAR das Tool installiert hat:

/usr/share/php/PHP/CodeSniffer

Was ich vielleicht noch dazu sagen sollte. Ich habe das ganze auf einem Debian System aufgesetzt, falls es also bei euren Linux Distributionen ein wenig anders läuft, dann wundert euch bitte nicht. Ihr könnt natürlich auch all eure Fragen und Anmerkungen hier im Kommentarbereich hinterlassen. Die Chance ist groß, dass sie jemand findet, der euch behilflich sein kann.

Verwendung

Da wir den PHP Code Sniffer soeben erfolgreich installiert haben und das Tool uns nun von überall auf der Kommandozeile zur Verfügung steht, können wir anfangen unsere Code ein wenig zu analysieren.

Fangen wie aber ganz einfach an. Wir erstellen eine einfache Klasse und schauen, ob wir sie gegen die Zend Framework Regeln verifizieren können. Da es sich hier um ein Tutorial handelt, nehmen wir natürlich eine Klasse, die dies nicht schafft. Um es mit den Worten eines berühmten Moderators zu sagen: „Ich habe da schon mal was vorbereitet“. Die badClass Klasse.

Lassen wir also PCS über unseren Code drüber laufen. Dies geht ganz einfach mit dem folgenden Aufruf

phpcs --standard=zend badClass.php

Ich denke der Parameter ist selbstredend, aber um sicher zu gehen, dass jeder es verstanden hat, --standard definiert den Standard, wer hätte es gedacht, der verwendet werden soll. Ein Standard ist einfach eine bestimmte Zusammenstellung von Regeln, die zur Validierung hinzugezogen werden. Alle weiteren Standard findet ihr unter /usr/share/php/PHP/CodeSniffer/Standards, wo wir am Tag vier auch unsere eigenen Standards hinpacken werden. Jetzt aber wieder zu unserem Beispiel. Der oben genannte Aufruf erzeugt den folgenden Output:

FILE: /var/www/phpcodesniffer/badClass.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
  5 | ERROR | Spaces must be used to indent lines; tabs are not allowed
  7 | ERROR | Spaces must be used to indent lines; tabs are not allowed
  8 | ERROR | Spaces must be used to indent lines; tabs are not allowed
 10 | ERROR | Spaces must be used to indent lines; tabs are not allowed
 13 | ERROR | A closing tag is not permitted at the end of a PHP file
--------------------------------------------------------------------------------

War ja ziemlich einfach. Der Zend Standard verbietet also die Verwendung von Tabs und das schließende PHP Tag am Ende einer Datei (was ich übrigens noch einen Beitrag wert finde). Ist einem diese Prüfung zu langweilig, der kann sich die gleiche Datei noch mal mit dem PEAR Standard ansehen.

FILE: /var/www/phpcodesniffer/badClass.php
--------------------------------------------------------------------------------
FOUND 11 ERROR(S) AND 0 WARNING(S) AFFECTING 6 LINE(S)
--------------------------------------------------------------------------------
  2 | ERROR | Missing file doc comment
  3 | ERROR | Missing class doc comment
  3 | ERROR | Class name must begin with a capital letter
  5 | ERROR | Line indented incorrectly; expected at least 4 spaces, found 1
  5 | ERROR | Spaces must be used to indent lines; tabs are not allowed
  5 | ERROR | Class constants must be uppercase; expected MYCONSTANT but found
    |       | MyConstant
  7 | ERROR | Spaces must be used to indent lines; tabs are not allowed
  7 | ERROR | Missing function doc comment
  7 | ERROR | Line indented incorrectly; expected 4 spaces, found 1
  8 | ERROR | Spaces must be used to indent lines; tabs are not allowed
 10 | ERROR | Spaces must be used to indent lines; tabs are not allowed
--------------------------------------------------------------------------------

Man sieht, dass PEAR ein wenig strengere Regeln besitzt, was ich gut finde. Prinzipiell sieht das Ganze aber fast identisch aus. Reparieren wir unsere Datei nun und versuchen wir es noch mal neu. GoodClass.

phpcs --standard=zend goodClass.php

Leider gibt es überhaupt keinen Output, falls man eine Datei Sniffed, die keine Verletzungen aufweißt. Dies kann man aber ganz einfach mit -v ändern. Dieser Parameter macht PCS ein wenig gesprächiger und lässt ihn folgenden Output produzieren:

Registering sniffs in Zend standard... DONE (15 sniffs registered)
Processing goodClass.php [36 tokens in 11 lines]... DONE in < 1 second (0 errors, 0 warnings)

Eigentlich wollte ich ja heute noch ein wenig auf die Verwendung der anderen Parameter eingehen, was ich aber doch lieber auf morgen verschiebe, da ich nicht zu viel in einen Beitrag reinpacken will. Morgen geht es also weiter mit den wichtigsten Parametern und der Zusammenstellung der ersten eigenen Regelsätze.

Ü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

21 Comments

  1. Irgendwie wirft sich auch hier bei mir mal wieder die Frage auf warum einrücken mit Leerzeichen besser sein soll als mit Tabs. Bei Tabs kann sich schließlich jeder Entwickler die weite (optisch) so einstellen wie er möchte, das geht bei Tabs nicht. Wäre nett wenn mich mal jemand über den Vorteil von Leerzeichen aufklären könnte.

    Reply
  2. @Ben: Die Bedienung mittels Tab kann ja dennoch in der gespeicherten Datei die benötigte Anzahl an Leerzeichen hinterlassen. Einfach den Editor nach den eigenen Wünschen konfigurieren.

    Reply
  3. Ich finde die Leerzeichen deswegen besser, weil man dadurch (meiner Meinung nach) die bessere Kontrolle über die Weite hat. Zum einen, wenn man mit unterschiedlichen Editoren arbeitet, die unterschiedlich eingerichtet sind (ok, das kann man in jedem Programm ein mal sauber umsetzen) und zum anderen ist es praktisch bei Änderungen, die man teilweise auf die schnelle mal von einem fremden Rechner über WebFTP umsetzen muss (tab in einer Textarea ist ein bisschen schwer ;)).

    Ok, das waren jetzt wahrscheinlich nicht wirklich überzeugende Argumente, aber das waren die Hauptgründe, warum ich von Tabs auf Leerzeichen umgestiegen bin.

    Reply
  4. 1. Ohje – da wird einem erstmal bewusst wie weit man oft von einem Standard weg ist bei verwendeten Klassen. Aber einige dinge die mir der Output um die Ohren wirft wusste ich nicht und hatte ich auch noch nirgends gelesen von daher danke für den Tipp werde künftig dank phpcs wohl etwas näher am Standard sein 🙂

    2. Oh ja – bitte mehr zum Thema „das schließende PHP Tag am Ende“, mir ist bereits bei einigen Codes Aufgefallen das das schließen wohl aus der Mode gekommen ist. Was hat es damit auf sich ? Seit php3 bin ich es schließlich gewohnt das ein Script geschlossen gehört und nun soll gerade das schlecht sein ?

    Reply
  5. @Marco: Der PHP Interpretor macht das Tag von sich aus selber zu. Du hast also nicht das Problem, dass du am Ende der Seite nochmal ein Space oder sowas drinnen hast, das automatisch die Header sendet. Aber um ehrlich zu sein finde ich es auch unschön.

    Reply
  6. ok, das leuchtet ein also wenn man ordnungsgem. kein space oder sonst was nach dem letztem tag hat sollte es ja auch nicht weiter stören 😉

    Reply
  7. Ich hab das ganze mal über ein größeres Projekt laufen lassen – man man, das verbaucht aber ne ganze Menge Arbeitsspeicher!

    Reply
  8. Zum Thema Leerzeichen vs. Tabs hatte ich mir auf diese Seite mal ein Lesezeichen gesetzt: http://www.wikiservice.at/dse/wiki.cgi?EinzigWahreEinr%FCckTiefe . Ich finde die Seite beschreibt ganz gut die Vor- und Nachteile.

    Ich verwende auch grundsätzlich nur Spaces, weiß aber auch nicht so recht warum. Ich glaube die ersten Arbeitgeber waren dafür entscheidend und man hat es dann so übernommen. Ich glaube grundsätzlich ist das wohl eine Glaubensfrage.

    @Nils
    Beinhaltet das Tutorial am Freitag auch eine Einbindung der Regeln in eine IDE? Weil das wäre ja eigentlich wirklich interessant / wünschenswert, ich will ja nicht erst beim „deployen“ die Regelverletzung aufgezeigt bekommen sondern gleich beim „coden“.

    Viele Grüße
    Ulf

    Reply
  9. @Ulf: Nein, leider habe ich den Code Sniffer bis jetzt auch nur in mein Cruise Control integriert. Am nächsten Dienstag werde ich aber mit einem hochtalentierten Eclipse Entwickler ein kleines Plugin schreiben. Erstmal geht es nur um das Springen zu Codezeilen über einen Link. Aber vielleicht kennt er sich ja auch mit Checkstyle aus. Denn wenn der gleiche Output raus kommt, dann sollte Eclipse das ja verarbeiten können.

    Reply
  10. Das mit dem Eclipse Plugin hört sich ja nett an. Ansonsten kann man ja auch im Eclipse Externe Programme einbinden und den output sich in einer Konsole anzeigen lassen. Prüfung auf Knopfdruck – besser als nichts.

    Reply
  11. Super Nils, ich warte auf das Tutorial „Integrating PHP Code Sniffer into an IDE“ auch gerne noch ein paar Wochen! 🙂

    Mach weiter so, macht immer Spaß jeden Tag den Eintrag zu lesen!

    Reply
  12. Ich validiere meine Skripte nach Zend und erhalte die Fehlermeldung, dass ein \n\r anstelle eines \n verwendet wird. Leider finde ich keinerlei Optionen in Eclipse, wo ich die Formatierung des Zeilenumbruch einstellen kann.
    Hast du da eine Idee?

    Reply
  13. @Roman:
    Hab auch eine kleine Weile gebraucht um es zu finden:
    Window > Preferences > General > Workspace:
    New text file line delimiter: Other: Unix

    Grüße

    Reply

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