PHP Codesniffer ist ein in PHP geschriebens Tool, welches PHP Code analysieren kann und Verstöße gegen Programmierrichtlinien meldet. PHP Tool Integration (PTI) ist ein Eclipseplugin, welches es ermöglicht, den Codesniffer direkt als Codevalidator zu verwenden, wodurch die Fehler direkt während der Entwicklung schon in Form von Warnings oder Errors angezeigt werden.

Installiert wird der Codesniffer über den Updatemanager (Help -> Install New Software…), hier die Update-URL “http://www.phpsrc.org/eclipse/pti/” eintragen und den Sniffer, sowie wahlweise auch PHPUnit installieren. In den globalen Einstellungen kann man nun einen Standard wählen, Zend und PEAR sind relativ strikt, General enthält typische Regeln, ich habe mich allerdings entschieden, mir aus den vorhandenen Regeln einen eigenen Standard zu erstellen.

Aber zuerst zur Konfiguration:
Oben wird eine lokal installierte PHP Binary gewählt werden, darunter wählt man optional eine PEAR Bibliothek, <internal> wird mitgeliefert und reicht völlig aus. Während man sich einen eigenen Standard zusammenstellt oder nicht nachvollziehen kann, welche Regel einen bestimmten Fehler wirft, empfiehlt es sich den Debugmodus zu aktivieren. Darunter sind nun die vordefinierten Standards zu finden, hier wählen wir später unseren Standard als “default”, aktuell existiert dieser aber noch nicht. Unten sollte man nur noch einstellen, wie breit ein Tab ist und bestätigt erst einmal mit OK.

Testen kann man das ganze nun mit dem Generic-Standard, indem man einen Ordner, ein Projekt oder eine Datei im Navigator wählt und im Kontextmenü unter dem Punkt “PHP Tools” den “PHP Code Sniffer” klickt. Hat man in den Einstellungen den entsprechenden Validator aktiviert, muss man eine geöffnete Datei nur speichern oder explizit validieren.


Im Quelltext werden nun “Fehler” markiert:

Eine der gesetzten Regeln besagt, dass ein String nicht in double quotes eingeschlossen sein darf, falls dies nicht unbedingt nötig ist (Nötig wäre es z.B. bei einem manuellen Zeilenumbruch im String). Nachdem man nun die double quotes gegen quotes getauscht hat und die Datei gespeichert hat, verschwindet der Fehler.

Erstellen eines eigenen Standards:

Den Pfad zu den Standards musste ich selbst auch erst suchen, er ist tief im plugins Verzeichnis von Eclipse versteckt:

/plugins/org.phpsrc.eclipse.pti.library.pear_1.1.1.R20091122000100/php/library/PEAR/PHP/CodeSniffer/Standards

Die Verzeichnisstruktur sieht hier folgendermaßen aus (daran muss sich gehalten werden, wenn der eigene Standard funktionieren soll, da hier mit autoload gearbeitet wird!).

Als Vorlage nehmen wir den Zend-Standard und kopieren erstmal das Verzeichnis nach MyStandard, das Unterverzeichnis Sniffs (so werden einzelne Regeln bezeichnet) solle bestehen bleiben, den Inhalt können wir jedoch erst einmal löschen. Die Datei ZendCodingStandard.php wird umbenannt in MyStandardCodingStandard.php und der Inhalt angepasst, in Zeile 33 muss der Klassenname stimmen, aus

class PHP_CodeSniffer_Standards_Zend_ZendCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard{

wird

class PHP_CodeSniffer_Standards_MyStandard_MyStandardCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard

Nicht vergessen, den Standard in den Einstellungen als “default” zu setzen, dies geht entweder global oder pro Projekt, sobald der Ordner erstellt ist.
Nun können weiter unten in der Methode “getIncludedSniffs()” vorhandene Regeln aus allen Standards zusammengestellt werden, die Dateinamen sollten aussagekräftig genug sein, ansonsten gibts es eigentlich in allen Sniffs entsprechende Kommentare.

    public function getIncludedSniffs()
    {
        return array(
                'Generic/Sniffs/Functions/OpeningFunctionBraceBsdAllmanSniff.php',
                'Generic/Sniffs/PHP/DisallowShortOpenTagSniff.php',
                'Generic/Sniffs/WhiteSpace/DisallowTabIndentSniff.php',
                'PEAR/Sniffs/Classes/ClassDeclarationSniff.php',
                'PEAR/Sniffs/ControlStructures/ControlSignatureSniff.php',
                'PEAR/Sniffs/Files/LineEndingsSniff.php',
                'PEAR/Sniffs/Functions/FunctionCallArgumentSpacingSniff.php',
                'PEAR/Sniffs/Functions/FunctionCallSignatureSniff.php',
                'PEAR/Sniffs/Functions/ValidDefaultValueSniff.php',
                'PEAR/Sniffs/WhiteSpace/ScopeClosingBraceSniff.php',
                'Squiz/Sniffs/Functions/GlobalFunctionSniff.php',
               );

    }//end getIncludedSniffs()

Zusätzlich zu den hier aufgezählten “externen” Regeln kann man nun eigene Sniffs erstellen, in dem ein Ordner mit der entsprechenden “Kategorie” im Verzeichnis “Sniffs” angelegt wird, z.B. “Array”, hier muss nun eine PHP Datei angelegt werden, deren Dateiname mit ..Sniff.php enden muss, dieser Sniff wird dann vom CodeSniffer automatisch geladen. Wichtig ist, dass der Klassenname innerhalb der Datei stimmt: Die Datei “/MyStandard/Sniffs/Arrays/ArrayDeclarationSniff.php” muss diesen Klassennamen tragen:

class MyStandard_Sniffs_Arrays_ArrayDeclarationSniff implements PHP_CodeSniffer_Sniff

Hat man sich seinen Standard zusammengestellt, ist aber mit Details eines bestimmten Sniffs so nicht zufrieden, kopiert man ihn sich einfach in seinen Standard und entfernt ihn aus dem array, in dem die externen Sniffs definiert sind. Zusätzlich passt man noch den Klassennamen an und ändert die entsprechende Stelle im Code.

Hinterlasse einen Kommentar.

Network-wide options by YD - Freelance Wordpress Developer