Artikelformat

Code Sniffer – ein Update

Der CodeSniffer wird immer weiter entwickelt und mit der neusten Version werden die Standards von PHP-Klassen zu xml-Definitionen umgestellt. Dies hat den Vorteil, dass diese übersichtlicher sind und einige neuen Funktionen Einzug erhalten. Zum Entstehungszeitpunkt dieses Artikel ist die neue Version des CodeSniffers noch im Beta-Stadium. Entwickler die mit der Zeit gehen – insbesondere welche die CI-Server verwalten – sollten aber trotzdem schon einen Blick auf diese Neuerung werfen, um bei dem nächsten Update nicht überrascht zu sein.

Wenn man bereits einen eigenen Standard definiert hat, so kann man diesen in das neue xml-Format übertragen. Als Beispiel nehme ich einen modifizierten PEAR-Standard mit dem einfallsreichen Namen PEARMOD.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
if (class_exists('PHP_CodeSniffer_Standards_CodingStandard', true) === false) {
    throw new PHP_CodeSniffer_Exception('Class PHP_CodeSniffer_Standards_CodingStandard not found');
}
 
class PHP_CodeSniffer_Standards_PEARMOD_PEARMODCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard {
 
    public function getIncludedSniffs() {
        return array(
                'PEAR',
                'Generic/Sniffs/Functions/OpeningFunctionBraceKernighanRitchieSniff.php'
        );
 
    }//end getIncludedSniffs()
 
    public function getExcludedSniffs() {
        return array(
                'Generic/Sniffs/Functions/OpeningFunctionBraceBsdAllmanSniff.php',
                'PEAR/Sniffs/Functions/FunctionDeclarationSniff.php',
                'PEAR/Sniffs/Classes/ClassDeclarationSniff.php'
        );
    }
 
}//end class
?>

Dieser Standard setzt auf dem PEAR-Standard auf, was man an der Zeile PEAR in der getIncludedSniffs-Methode erkennen kann. Da ich ein Freund der Kompaktheit bin möchte ich die öffnende geschweifte Klammer am Ende der Zeile und nicht in einer neuen Zeile sehen. Das ist übrigens die große Änderung zu PEAR.
Also wird der KernighanRitchie-Stil noch inkludiert und BSDAllman auf exclude gesetzt. In den Funktion- und Klassendeklaration-Sniffs wird die Klammerung wieder überprüft. Daher entferne ich diese ebenfalls.

Jetzt wird daraus eine xml-Definition. Zuerst wird im Verzeichnis des alten Standards eine Datei mit dem Namen ruleset.xml angelegt. Als ersten Text schreibt man hier das Encoding und den Root-Tag der xml-Datei in diese Datei.

1
2
3
<?xml version="1.0"?>
<ruleset name="PEARMOD">
</ruleset>

Wir bauen hier auch wieder auf dem PEAR-Standard auf, daher referenzieren wir diesen.

1
2
3
4
<?xml version="1.0"?>
<ruleset name="PEARMOD">
	<rule ref="PEAR" />
</ruleset>

Bisher haben wir nur eine Kopie von PEAR unter einem neuen Namen. Jetzt sagen wir dem CodeSniffer, welche Sniffs wir nicht aus PEAR übernehmen. Dabei wird Sniffs aus dem Klassennamen entfernt; ebenso das angehängte Sniff. Weiter werden die Unterstriche durch Punkte ersetzt und man erhält somit:

1
2
3
4
5
6
7
8
<?xml version="1.0"?>
<ruleset name="PEARMOD">
	<rule ref="PEAR">
		<exclude name="Generic.Functions.OpeningFunctionBraceBsdAllman"/>
		<exclude name="PEAR.Functions.FunctionDeclaration"/>
		<exclude name="PEAR.Classes.ClassDeclaration"/>
	</rule>
</ruleset>

Zum Schluß ergänzen wir noch die alternative Regel zur Klammerung und schon haben wir unseren alten Standard auf die neue Version des CodeSniffers portiert.

1
2
3
4
5
6
7
8
9
10
<?xml version="1.0"?>
<ruleset name="PEARMOD">
	<rule ref="PEAR">
		<exclude name="Generic.Functions.OpeningFunctionBraceBsdAllman"/>
		<exclude name="PEAR.Functions.FunctionDeclaration"/>
		<exclude name="PEAR.Classes.ClassDeclaration"/>
	</rule>
 
	<rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie" />
</ruleset>

Jetzt noch eine Besonderheit. Man kann die Sniffs auch in der ruleset.xml umkonfigurieren. Nehmen wir bspw die Zeilenlänge. Normalerweise wird bei 80 Zeichen eine Warnung ausgegeben und ab 100 ein Fehler. Man kann dies nun bspw so umkonfigurieren, dass ab 70 Zeichen eine Warnung gemeldet wird. Ein Fehler aber nicht auftritt. Somit würde man die LineLength Regel inkludieren und mit entsprechenden Properties anpassen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version="1.0"?>
<ruleset name="PEARMOD">
	<rule ref="PEAR">
		<exclude name="Generic.Functions.OpeningFunctionBraceBsdAllman"/>
		<exclude name="PEAR.Functions.FunctionDeclaration"/>
		<exclude name="PEAR.Classes.ClassDeclaration"/>
	</rule>
 
	<rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie" />
 
	<rule ref="Generic.Files.LineLength">
		<properties>
			<property name="lineLimit" value="70" />
			<property name="absoluteLineLimit" value="0" />
		</properties>
	</rule>
</ruleset>

Persönlich freue ich mich schon auf die Version 1.3.x des CodeSniffers. Diese Art der Definition gefällt mir nämlich sehr gut.

2 Kommentare

  1. Dem kann man sich nur anschließen. Der Release Candidate ist schon draußen, lange kanne es ja nicht mehr dauern bis das finale Release kommt.

    Antworten
  2. Ich habe heute unsere phpundercontrol Umgebung upgedated und direkt einen Rundumschlag gemacht: PHP 5.3.3, neues Cruisecontrol, neues phpundercontrol, alle pear und pecl Module neu (phpunit 1.5.2, aktuelle phpdoc, phpmd, pdepend, phpcpd, phploc, phpdoc, phpcb), und unseren alten CodeSniffer Standard rüberkopiert. Als dann die Fehlermeldung kam musste ich gleich an deinen Artikel denken und sah bei den anderen Standards die rules.xml.

    Ich finde sie auch schöner muss ich sagen, gerade die Parametrisierung wird in Zukunft noch bessere Anpassungsmöglichkeiten bieten.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.