PHP Coding Standards: bitte so einfach wie möglich, aber nicht einfacher
Je komplexer und umfangreicher bestimmte Standards sind, desto schwerer ist es sie einzuhalten. Noch schwieriger wird es, wenn die Standards unlogisch erscheinen oder schlicht und ergreifend unpraktisch sind.
Anders ausgedrückt: je einfacher, verständlicher und praxisbezogener ein Standard ist, desto höher ist die Wahrscheinlichkeit, dass er von der Entwicklergemeinde akzeptiert und durchgesetzt wird.
Dabei mangelt es nicht an Vorlagen im PHP-Sektor. Als Beispiele seien nur genannt die Coding Guidelines von PEAR, Zend Framework Coding Standard und die Doctrine Coding Standards
Wer sich allerdings im Detail schon mit dem ein oder anderen Vorschlag beschäftigt hat, wird garantiert den ein oder anderen Reibungspunkt entdeckt haben.
Warum soll die maximale Zeilenbreite auf 80 Zeichen begrenzt bleiben?
Wir haben heute nicht nur riesige Monitore. Wir haben auch ein anderes PHP. Entwurfsmuster, Objektorientierung und Frameworks haben in die Skriptsprache Einzug gehalten und der Zugriff auf Objekte, Objektmethoden und Objektattribute hat nun mal seinen Preis. Vor allem, wenn im selben Dokument dann noch empfohlen wird, keine kryptisch kurzen Variablen und Methodennamen zu wählen, sondern möglichst beschreibende Namen zu finden, die gerne auch etwas länger sein dürfen. WTF!??!
Warum sollen bekannte Abkürzungen verhunzt werden?
URL müsste demnach im CamelCase zu Url, HTML zu Html und PHP zu Php werden. Tut mir leid, das ist einfach nur grausam, rein intuitiv habe ich die folgende Schreibweise schon immer angewandt:
$someURL = $this->getURL();
Warum soll ich zum Einrücken von Code Leerzeichen benutzen und keine TABS?
Ich kenne kein sinnvoll nutzbares Entwicklungswerkzeug, das damit nicht umgehen könnte. Ich kenne auch keine Tastatur, deren Leertaste diese Tortur auf Dauer überleben würde. Spass beiseite - TABS zum Eintrücken sind einfach nur praktisch. Wer nicht in der Lage ist, seine IDE entsprechend einzustellen sollte vielleicht doch noch mal einen Termin beim Berufsberater in Erwägung ziehen. Anpassungen in beide Richtungen sind machbar -> TABS in SPACES umwandeln und SPACES in TABS. Jeder kann seinen Keks haben und darf ihn auch essen...
Warum soll ich meinen Quelltext künstlich durch die Klammersetzung aufblähen?
Mir ist klar, dass das einen Glaubenskrieg auslösen kann. Gemeint ist die geschweifte Klammer. Für mich unnötig in die Länge gezogen ist folgendes Beispiel:
if ($someCond === $someValue)
{
doSomething();
}
else
{
doSomethingElse();
}
Die Argumente sind mir klar. Angeblich kann man die Klammern besser erkennen und so Klammerfehler schneller finden. Das stimmt vielleicht bei so einem kleinen Beispiel. Bei echtem Code hilft mir dabei aber doch schon die IDE...
Warum müssen Coding Standard ewig lang und umfangreich sein?
Wenn ich zurückdenke an die Zeit als Java Coding Guidelines für mich selbst noch eine Rolle gespielt haben, läuft mir immer wieder ein kleiner Schauer über den Rücken. Seitenweise Anweisungen, Anleitungen und Ansagen...klar, dass das irgendwann zu einem Speicherüberlauf kommen muss.
Warum gibt es keinen sinnvollen, kurzen und praktikablen Standard?
Es gibt ihn doch. Und zwar im FLOW3-Projekt
Die PHP-Entwickler um Robert Lemke haben es wirklich verstanden, einen kompakten, plausiblen und nachvollziehbaren Satz von Regeln zu erstellen, die dem Webentwicker das Leben erheblich erleichtern.
Vor allem werden dabei auch Techniken vorausgesetzt (Dokumentation, Versionsverwaltung) die per se schon zu einer besseren Codequalität und zu professionellem Web Engineering führen.
Und das allerbeste: die Regeln lassen sich auf einem DIN A 4 Blatt zusammenfassen.