Programmierer machen, wie jeder andere Mensch, auch Fehler. Nun gibt es zum einen Fehler in der Syntax, auf der anderen Seite gibt es die Logik-Fehler. Beide verursachen, dass ein Programm entweder gar nicht oder nicht wie erwartet funktioniert. Normalerweise kann (und muss) man diese Fehler entdecken – manchmal geht das leicht, manchmal aber auch nicht. Syntax-Fehler stellen hier den einfachsten Kandidaten dar, da diese meist schon von der verwendeten IDE erkannt werden, spätestens aber bei der Ausführung des Programms ein Fehler auftritt. Logische Fehler sind da schon etwas kniffliger, da sie rein aus Programmiersicht fehlerfrei sind. Nur die Art und Weise, wie sie ein Problem behandeln entspricht nicht dem, was der Programmierer ursprünglich vor hatte.
Zu diesen beiden Kandidaten gesellt sich aber noch eine weitere Gattung, nämlich die Art und Weise, wie Code geschrieben wird. Jeder Programmierer hat – genauso wie jeder Mensch die eigene Handschrift – einen eigenen Programmierstil. Das ist zuersteinmal nichts verwerfliches und wird weder Probleme in der Syntax noch in der Logik hervorrufen. So gesehen gibt es aus betriebswirtschaftlicher Sicht keinerlei Notwendigkeit, sich darum zu kümmern. Problematisch wird es aber dann, wenn mehrere Entwickler mit einem Projekt beschäftigt sind. Spätestens hier treffen Welten auseinander und es kann durchaus vorkommen, dass völlig korrekter Code einfach nicht mehr bzw. nur sehr schwer lesbar ist. Bei geringem Umfang stellt das nicht das große Problem dar, wenn man allerdings mit komplexen Projekten zu tun hat kann dies zu einem großen Hindernis werden. Das fiese daran ist, dass man das Problem anfangs einfach nicht erkennt. Wenn es dann auftritt, ist es meist zu spät.
Um dem Herr zu werden, setzen viele Unternehmen und Entwickler auf Coding-Standards. Dabei handelt es sich um Regeln, wie Code formatiert werden muss und welche Lösungswege nicht verwendet werden sollten. Oder eben, welche Prioritäten bestimmte Lösungswege haben. Dabei geht es z.B. um die Art und Weise, wie Klammern gesetzt werden, die Variablen formatiert werden, wie Klassen und Kontrollstrukturen (Schleifen usw.) auszusehen haben usw. Gerade große Open Source Projekte mit mehreren hundert oder gar tausend Entwicklern müssen einfach derartige Regeln definieren, da sonst reinstes Chaos entsteht. Das würde dann dazu führen, dass Code zwar sehr gut, aber aufgrund von schlechter Lesbarkeit nicht mehr wartbar wäre. Und somit leider unbrauchbar sein würde.
Ok, nun haben wir die Theorie geschafft. Nun kann man die Regeln definieren und jeder hält sich dran, aber wie es so bei den Menschen ist, unterlaufen einem Fehler, man wird faul oder man hat einfach keine Lust auf die Regeln. Die gegenseitige Kontrolle von Code mag bei kleineren Mengen noch durch Menschen machbar sein, wenn ein Projekt aber aus mehreren zehntausenden Zeilen Code besteht, ist das auch nicht mehr machbar. Und an dieser Stelle setzt man auf statische Code-Analyse. Mit den entsprechenden Tools kann man Code analysieren und anschließend anhand definierter Regeln auswerten lassen.
Eines dieser Tools, und das sagt ja schon die Überschrift, befasst sich mit der statischen Analyse von php Code und nennt sich “php code sniffer”. Das Tool ist kostenlos und kann über PEAR geladen werden:
pear install PHP_CodeSniffer-1.3.0RC2
Die Version 1.3 RC2 ist die derzeit aktuelle Version, um auf dem neusten Stand zu sein schaut doch einfach mal hier nach, welche die aktuelle Version ist.
Über die Console ist das Tool nach erfolgreicher Installation mittels “phpcs” verfügbar. Der Aufruf ist dann ganz leicht:
phpcs --standard=zend class.php
In diesem Beispiel wurde die Datei class.php auf die Coding-Standards von Zend hin überprüft. Das Ergebnis sieht dann ungefähr so aus:
FILE: /.../class.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
1 | ERROR | End of line character is invalid; expected "\n" but found "\r\n"
9 | ERROR | Expected 0 spaces before opening brace; 2 found
11 | ERROR | Spaces must be used to indent lines; tabs are not allowed
Als kurze Erklärung: In Zeile 1 wurde ein falscher Zeilenumbruch verwendet (kann passieren, wenn man mit Windows und Linux/Unix im Wechsel am gleichen Code arbeitet), in Zeile 9 waren zwei Leerzeichen vor der öffnenden geschweiften Klammer und in Zeile 11 wurde mit Tabs an Stelle von Leerzeichen eingerückt. Die Datei an sich funktioniert tadellos, allerdings verstoßen diese Punkte eben gegen die Konventionen von Zend.
Wie ihr seht, ist es mit dem php code sniffer sehr schnell und vor allem sehr einfach möglich, euren Code auf Regeln hin zu untersuchen und Fehler dieser Art zu finden. Neben den Regeln von Zend gibt es noch einige weitere vorgefertigte Rules, die ware Stärke zeigt das Tool aber mit der Möglichkeit, eigene Regeln zu definieren. Da ich den Umfang dieses Beitrags nicht sprengen will, schaut euch doch einfach mal folgenden Beitrag auf “php hates me” an, der genauer auf dieses Thema eingeht: PHP Code Sniffer – Eigene Regeln erstellen.
Links:
php code sniffer
phphatesme.com