• PHP Code Sniffer – Installation und Verwendung

    von Nils Langner am 10. März 2009

    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.

    Nils Langner 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

    21 Kommentare »


    • PHP hates me - Der PHP Blog » Statische Code-Analyse mit dem PHP Code Sniffer
      am 10. März 2009 um 08:36 Uhr

      [...] PHP-Code-Sniffer installieren und verwenden [...]


    • Ben
      am 10. März 2009 um 11:18 Uhr

      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.


    • Ben
      am 10. März 2009 um 11:19 Uhr

      *keuch*, natürlich meinte ich das man die Weite bei Leerzeichen nicht einstellen kann.


    • Malte
      am 10. März 2009 um 19:09 Uhr

      @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.


    • Daniel
      am 10. März 2009 um 19:49 Uhr

      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.


    • Marco
      am 10. März 2009 um 19:55 Uhr

      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 ?


    • admin
      am 10. März 2009 um 20:03 Uhr

      @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.


    • Marco
      am 10. März 2009 um 21:03 Uhr

      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 ;)


    • Dennis Becker
      am 11. März 2009 um 08:18 Uhr

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


    • PHP hates me - Der PHP Blog » PHP Code Sniffer - Parameter und eigene Regelsets (Standard)
      am 11. März 2009 um 09:34 Uhr

      [...] hatten wir über die Installation und die erste Verwendung des PHP Code Sniffers (PCS) geredet. Heute werde ich noch ein wenig über die Parameter reden, die ich gestern noch nicht [...]


    • Ulf
      am 11. März 2009 um 10:36 Uhr

      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


    • admin
      am 11. März 2009 um 17:04 Uhr

      @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.


    • Malte
      am 11. März 2009 um 19:25 Uhr

      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.


    • Ulf
      am 11. März 2009 um 19:45 Uhr

      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!


    • bitExpert Blog » Blog Archive » Copy & Paste Detection für PHP
      am 15. März 2009 um 22:11 Uhr

      [...] Wer übrigens mehr zum Thema PHP_CodeSniffer wissen möchte sollte mal bei Nils vorbeischauen. Er bloggte in der letzten Woche ausführlich zum Thema PHP_CodeSniffer. [...]


    • Roman
      am 14. April 2009 um 18:49 Uhr

      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?


    • admin
      am 14. April 2009 um 18:58 Uhr

      Vielleicht das Encoding umstellen? Wo genau das geht, habe ich leider gerade keine Ahnung.


    • Roman
      am 14. April 2009 um 21:51 Uhr

      mit dem Enconding habe ich schon fleißig rumgespielt. Bisher konnte ich “den Fehler” aber noch nicht finden.


    • Refactoring des Example Projekts | Creative Developer Service
      am 13. Mai 2009 um 23:55 Uhr

      [...] ANT Manual CruiseControl Config CodeSniffer Deutsche ausführliche Anleitung von Nils Langner (PHP hates me) [...]


    • Seong
      am 26. Juli 2009 um 14:55 Uhr

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

      Grüße


    • PHP Tool Integration – PHP CodeSniffer | Some Code Blog
      am 15. November 2009 um 12:20 Uhr

      [...] den CodeSniffer nicht kennt, dem kann ich unter anderem den Blogeintrag von Nils Langer über die Installation und Verwendung vom CodeSniffer [...]

    RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

    Einen Kommentar hinterlassen

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.