Vorwort

Bevor ich hier auf die verschiedenen Vorteile des PHP Coding Standards eingehe, möchte ich den Autoren von "Programming in C++ - Rules and Recommendations":

Mats Henricson
Erik Nyquist

und dem Übersetzer "Joseph Supanich" danken. Ohne diese drei Personen wäre dieser Coding Standard nicht möglich gewesen. Außerdem habe ich mich von Paul Waring und Fredrik Kristiansen inspirieren lassen.

Anstatt Name wird im Coding Standard oft das Wort "Bezeichner" verwendet. Gültige Programmierbeispiele werden farblich von ungültigen abgehoben. So ist leichter zu erkennen, wo der PHP Coding Standard eingehalten wird und wo nicht.
Wenn im Text das Wort "Variable" steht und es um den Bezeichner bzw. die Definition eines (Variablen)Namens geht, so kann an die Stelle auch "Funktion", "Konstante" etc. stehen. Die Namenskonvention für Bezeichner sind global gültig. Ausnahmen, zum Beispiel für Bezeichner bei Klassen, werden explizit aufgeführt und erklärt.

Es gibt jetzt schon einige Coding Standards für PHP. Die Auswahl sollte einem Programmier-Team nicht schwer fallen, aber sorgfältig gemacht werden, denn ein Coding Standard hat keinen Sinn, wenn er nicht von allen Programmierern eingehalten wird.

Sinn und Zweck dieses Dokuments ist nicht, einen einzigen gültigen PHP Coding Standard zu entwerfen. Es wird in jedem Team bestimmte Anforderungen und Vorlieben geben. Das ist ok.
Es ist nicht ok, wenn jeder Programmierer seinen Vorlieben nachgibt und eine Variable, mal so und mal anders benennt. Dieses muss durch Kontrollen und Teamwork, am besten durch Extreme Programming, sichergestellt werden. "Extreme Programming" wird hier genannt, weil es das "Pair Programming" vorschlägt, das automatisch ein 4-Augen-Prinzip enthält.

Wenn man sich für einen Coding Standard entschieden hat, sollten alle Änderungen, die man vornimmt, schriftlich niedergelegt werden. Jede Regel, die vom Team abgelehnt wird, sollte abgeändert oder gelöscht werden. Jedoch muss beides dokumentiert werden, schon damit sich jeder an die Änderung halten kann. Auch neue Mitglieder im Team werden sich dann leichter zurechtfinden und keine Regeln befolgen, die veraltet sind.
Wenn Sie es vorziehen allein zu arbeiten, brauchen Sie keinen Coding Standard. Sie brauchen auch keine Kommentare oder sprechende Variablen. Aber wenn Sie planen, Ihr Projekt zu veröffentlichen (zum Beispiel bei sourceforge.net), dann sollten Sie es von Anfang an richtig machen. Gerade in der PHP-Welt ist die Wahrscheinlichkeit groß, dass Sie bei einem GPL-Projekt Hilfe bekommen. Früher oder später werden sich diese Helfer Ihren PHP-Code ansehen und das Ergebnis sollte sich doch sehen lassen können, oder?

Zu meiner Person: Ich, Claus van Beek, bin in fünf große Projekte involviert gewesen oder ich bin es noch. Bis auf eine Ausnahme, haben alle Projekte ohne Coding Standard angefangen und es wurden nahezu keine Tests durchgeführt. Konzepte wie Extreme Programming und/oder Refactoring wurden nie beachtet, obwohl diese Konzepte älter als PHP4 und PHP5 sind.
Beim XMB wurde zu Testzwecken das Feld "dummy" in die Datenbank eingefügt. Die Spalte blieb jedoch in allen RCs und der endgültigen Version erhalten. Nur deswegen musste zusätzliche Arbeit in das "ugrade.php" gesteckt werden.
In Papoo (Version 3.0) gibt es redundante und viele leere Felder in der Datenbank. Feststehende Begriffe wie "LAN" (Local Area Network) werden als Abkürzung für "language" verwendet. Schnittstellen von Methoden werden so gut wie nie dokumentiert. Die gewachsenen Strukturen wuchern immer mehr aus.

Oft höre ich auch Aussagen wie
"Das ist nur ein Test-Skript"
das bedeutet dann ungefähr: "Ich mache die Doku und die Kommentare später", aber viel zu oft passiert das nicht.

Zitat aus dem Internet

There is never time to do it right, but always time to do it twice.

Da ich in meinen Projekten den Azubis immer wieder predige: "Erst Strukturen, dann Coden, dann Tests", musste ich dieses Zitat verwenden, obwohl der Urheber unbekannt ist. Vielleicht ist es auch eine Abwandlung des Zitats von Jack Bergman: "There's never enough time to do it right, but there's always enough time to do it over."

Das Extreme Programming geht davon aus, dass erst die Modultests und dann der Code geschrieben wird. Ich stehe diesem Ansatz kritisch gegenüber, weil das schreiben von Tests manchmal ähnlich aufwendig ist, wie die Programmierung selbst. Die meisten Firmen und Programmierer arbeiten aber mit nur ganz wenigen Strukturen und verzichten auf automatisierte Tests. Ohne Refactoring, ohne (Modul)Tests und ohne PHP Coding Standard sind wachsende, ausufernde Strukturen und unverständlicher Programmcode unvermeidbar. Irgendwann kann das Projekt niemand mehr kontrollieren und die Fehlersuche wird enorm erschwert. Um das zu verhindern, müssen alle PHP-Projekte einen

einsetzen, um die Qualität der Software sicher zu stellen. Andere Verfahren wie Bug-Tracker-Systeme (wie Mantis) haben sich ebenfalls etabliert.