Kolumne: Der Rück-, Ein- und Ausblick auf das "PHP Extension and Application Repository"
Kommentare

Wer PHP_CodeSniffer noch nicht kennt, für den ist die kommende Version 1.4.0 eine gute Gelegenheit einzusteigen. Das Package spürt auf, ob Quellcode festgelegte Formatierungen und Regeln einhält. Trotz

Wer PHP_CodeSniffer noch nicht kennt, für den ist die kommende Version 1.4.0 eine gute Gelegenheit einzusteigen. Das Package spürt auf, ob Quellcode festgelegte Formatierungen und Regeln einhält. Trotz des Namens können Sie aber nicht nur PHP-Code prüfen, sondern auch JavaScript und CSS.

Nun scheint die Sicherstellung eines bestimmten Codierstils beziehungsweise Coding-Standards allein oder im Team eher eine untergeordnete Aufgabe zu sein. Die Erfahrung zeigt allerdings, dass so mancher unauffälliger Logik-Bug in Skripten allein dadurch aufgefallen ist, dass PHP_CodeSniffer die fehlende Einrückung eines if-Blocks bemängelt hat, der aber schon auf der richtigen Höhe steht, nur wurde ein vorheriger Block an der falschen Stelle geschlossen. PHP_CodeSniffer ist kein in sich geschlossenes Programm, das stur einen bestimmten Codierstil vorschreibt. Es umfasst stattdessen eine Vielzahl kleiner Klassen, die jeweils eine bestimmte Regel überwachen – diese Klassen heißen Sniffs. Sie können beliebig viele Sniffs zu einem Coding-Standard zusammenfassen. Bislang musste eine eigene Klasse implementiert werden, um einen eigenen Coding Standard aufzustellen, wenn die vorhandenen Klassen nicht ausreichten.

XML statt PHP

An dieser Stelle kommt die größte Neuerung der neuen Version: An Stelle einer Klasse tritt eine XML-Datei, in der im einfachsten Fall die erforderlichen Sniffs aufgelistet werden. Diese Umstellung hat eine ganze Reihe von Vorteilen: eine kompaktere Übersicht und schnelleres Bearbeiten. Fast entscheidender ist aber: Die Datei wird tatsächlich als Datei behandelt und eben nicht als eine „interne“ Klasse von CodeSniffer. Beim Aufruf des phpcs-Programms kann der vollständige Pfad angegeben werden: phpcs –standard=/der/Pfad/meineCS.xml Pfad/zum/Code. Soll ein Coding-Standard verteilt werden, reicht es aus, die Datei irgendwo abzulegen, statt wie bisher an die richtige Stelle in der PEAR-Installation zu schieben. Gerade im Zusammenspiel mit projektspezifischen Standards, Versionskontrollsystemen und der Zusammenarbeit mit Externen macht sich das positiv bemerkbar.

Parameter statt Klasse

Mit der Umstellung auf XML halten aber auch neue Fähigkeiten Einzug. Sniffs können jetzt Parameter übergeben werden. Prominentestes Beispiel ist die Prüfung der Zeilenlänge. Wenn eine andere Zeilenlänge als 80 Zeichen pro Zeile verwendet werden sollte, dann war eine eigene Sniff-Klasse erforderlich. Sie wurde von der originalen Klasse abgeleitet, um dann nur die erforderliche Klassenvariable auf den gewünschten Wert zu setzen. Jetzt reicht eine Anweisung in der XML-Datei. Allerdings müssen die bestehenden Sniff-Klassen dafür noch angepasst werden.

Qualität statt Quantität

Die nächste Neuerung betrifft den Umfang der Ausgabe. CodeSniffer hat bereits eine interne Gewichtung für Hinweise, bislang spielte es für die Ausgabe jedoch keine Rolle. Nunmehr soll aber über die XML-Datei auch festgelegt werden können, wann eine Meldung tatsächlich ausgegeben wird oder ignoriert werden soll. Und zu guter Letzt lässt sich der Meldungstext eines Sniffs auch anpassen beziehungsweise übersetzen.

Eine vollständige XML-Datei

Das Beispiel bildet eine XML-Datei ab, wie sie in einem realen System eingesetzt werden könnte, inklusive Kommentaren. Bedenken Sie lediglich, dass die neue Version mit der XML-Unterstützung derzeit noch im Alphastadium ist, und es durchaus noch zu Änderungen am Format kommen kann:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset name="Meine_Coding_Standards">
 <description>
  Das sind die Standards für das Produktivsystem.
 </description>

 <!-- Wir setzen auf den PEAR-Standard auf -->
 <rule ref="PEAR">
   <!-- Ausnahme:  true, false und null dürfen 
    auch groß geschrieben werden -->   
   <exclude name="Generic.PHP.LowerCaseConstant"/>
 </rule>

 <!-- Zusätzliche Regel: Generiere Hinweise, 
      wenn Todos enthalten sind -->
 <rule ref="Generic.Commenting.Todo"/>

 <!-- Die Zeilenlänge darf maximal 70 Zeichen betragen, 
      damit wir Hotfixes auch noch über die SSH-Konsole
      machen können -->
 <rule ref="Generic.Files.LineLength">
  <properties>
   <property name="lineLimit" value="70"/>
   <property name="absoluteLineLimit" value="0"/>
  </properties>
 </rule>

 <!-- Angepasste Meldung -->
 <rule ref="Generic.Commenting.Todo">
  <message>
   Im Produktivsystem dürfen keine Todos mehr drin sein!
   Es wurde aber das gefunden: %s
  </message>
 </rule>

 <!-- Meldungen über "falsche" Zeilenendungen sind nur 
      im Umgang mit dem VCS wichtig, fürs Produktivsystem 
      kann diese Meldung unterdrückt werden -->
 <rule ref="Generic.Files.LineEndings">
  <severity>0</severity>
 </rule>
</ruleset>  

Alexander Merz

Seit mehr als drei Jahren implementiert Alexander Merz im Redaktionssystem von Golem.de selbst die kuriosesten Wünsche der Redakteure und baut an der Golem.de-Webseite zur steten Unterhaltung der Leser. Sie erreichen ihn unter alexander.merz@gmail.com.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -