WordPress Coding Standards: Die Grundlagen

Auf dem WordCamp in Nürnberg habe ich auf dem Contributor Day einigen neuen Mitwirkenden die Einrichtung der WordPress Coding Standards in eine IDE erklärt. Hierbei kam dann die Bitte auf, doch mal mehr über die WordPress Coding Standards oder kurz WPCS zu schreiben. Dieser Bitte möchte ich gerne nachkommen. Doch bevor wir tiefgreifend in das Thema einsteigen, soll es heute erst einmal um die Grundlagen gehen.

Was sind Coding Standards

Einige von euch können vermutlich mit dem Begriff nichts anfangen. Bei Coding Standard oder auch Coding Conventions geht es um die Festlegung eines einheitlichen Programmierstils. Einige Programmiersprachen setzen einen strikten Programmierstil voraus. So ist es in der Programmiersprache Python zum Beispiel unabdingbar, eine korrekte Einrückung mit Tabs oder Spaces zu verwenden, da ansonsten der Code nicht wie gewünscht ausgeführt wird.

In PHP gibt es diese Voraussetzung nicht. Man könnte also auch alle Codezeilen ohne Einrückung schreiben oder sogar alles in eine Zeile. Dies sollte man aber in jedem Fall vermeiden. Denn solcher Code ist nur sehr schwer für einen Menschen lesbar und eine spätere Fehlersuche wird dadurch erheblich erschwert.

Zu PHP existieren diverse Standards, die sich etabliert haben. Einen einheitlichen Standard gibt es also nicht. Als den „offiziellsten“ könnte man die Standards der PHP Framework Interop Group bezeichnen. Diese hat die beiden Standards PSR-1 (Basic Coding Standards) sowie PSR-2 (Coding Style Guide) definiert.

Das Ziel von Coding Standards im Allgemeinen ist es, dass sich alle Entwickler auf einen gemeinsamen Programmierstil einigen. Das erleichtert die Einarbeitung in den Code eines anderen Entwicklers. Es erleichtert auch die Fehlersuche und hierdurch den Aufwand bei der Wartung von Quellcode.

Die WordPress Coding Standards

Auch die WordPress Community hat sich auf einheitliche Coding Standards geeinigt. Diese umfassen Regeln für PHP, HTML, CSS und JavaScript. Ich möchte hier jetzt nicht im Detail auf alle Regeln eingehen, die könnt ihr selbst nachlesen, aber die wichtigsten Punkte aufzählen. Hier unterscheiden sie sich zum Teil sehr stark von den PSR Standards.

  • Tabs statt (4) Spaces zum Einrücken verwenden
  • Öffnende Klammern bei Klassen und Funktionen auf der gleichen Linie
  • Alle Bedingungen in Klammern
  • Leerzeichen ohne Ende 🙂 Fast überall, mit ganz wenigen Ausnahmen (beispielsweise bei statischen Keys von Arrays)
  • Verwendung der Yoda-Condition

Gerade die Verwendung von sehr vielen Leerzeichen ist für Entwickler, die neu in die Programmierung von WordPress Plugins und Themes einsteigen eher gewöhnungsbedürftig. Auch die Yoda-Condition kennen viele Programmierer noch nicht. Schaut man in den WordPress Core, dann findet man auch sehr viele Dateien, bei denen die Coding Standards noch nicht umgesetzt wurden. Das liegt einfach auch daran, dass die Standards erste später eingeführt wurden und es nicht gewollt ist, den gesamten Core umzuschreiben. Es passiert also schrittweise, wenn ohnehin eine Codezeile geändert werden muss.

Beispiel für die WordPress Coding Standards

Hier mal ein kleines Beispiel eine Funktion, die einige der WordPress Codings Standards visualisiert:

function debug_cf7_add_error_to_ajax_response( $items, $result ) {
	if ( 'mail_failed' === $result['status'] ) {
		global $phpmailer;
		$items['errorInfo'] = $phpmailer->ErrorInfo;
	}
	return $items;
}
add_action( 'wpcf7_ajax_json_echo', 'debug_cf7_add_error_to_ajax_response', 10, 2 );

In diesem Beispiel erkennt man die vielen Leerzeichen, inkl. der Ausnahme bei Arrays, sowie eine Yoda-Condition.

Fazit

Ich hoffe, ich konnte euch in diesem ersten Artikel erst einmal erklären, was Coding Standards sind und wieso man sie einsetzen sollte. Nächste Woche werde ich euch ein Tool vorstellen, mit dem ihr euren Code lokal auf die Einhaltung der Coding Standards hin überprüfen könnt. In einem weiteren Artikel beschreibe ich dann die Einbindung des Tools in eine beliebte PHP IDE. Ihr dürft euch also noch auf mindestens zwei weitere Artikel zu dem Thema freuen 🙂

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugins, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

4 Kommentare » Schreibe einen Kommentar

  1. Hallo Bernhard,

    ein sehr toller Artikel über WPCS bzw. generell über Coding Standards. Ich freue mich schon auf die nächsten Artikel über WPCS. Da ich ein „kleiner“ Star Wars-Fan bin, finde ich das man die Yoda-Condition immer verwenden sollte.

    LG
    Daniel

  2. Danke für die gute Zusammenfassung.
    Es gibt einen Punkt, mit dem ich mich nicht anfreunden kann: die Yoda Notation!
    Die hier angeführte Argumente dagegen http://pushinginertia.com/2011/05/why-yoda-conditions-are-bad-and-usage-of-javas-final-keyword-is-good/, finde ich mindestens so überzeugend, wie die Argumente dafür. Nicht wegen den Kopfschmerzen beim lesen, so schwierig ist es nicht, wenn man den Trick mal kapiert hat. Aber es ist eben ein Trick, welcher nicht die Lesbarkeit (im Gegenteil zu allen anderen Regeln) sondern das Debuging, also das programmieren unterstützt. Warum wird er Entwickler aufgezwungen, die mit anderen Mitteln zum selben Resultat kommen. Zum Beispiel die im Gegenartikel angeführten Techniken der Modularisierung und der Testbarkeit der einzelnen Module. Es muss eh jeder Entwickler beide Schreibweise lesen können.

    Einmal mehr stellt sich die Frage, wo der Punkt überschreitet wird, wo Normierung über das Ziel hinausschiesst.

    • Also ich finde die Yoda-Condition gut, aber nur für den Vergleich auf Gleichheit. Bei Vergleichen auf größer oder kleiner finde ich sie auch schwierig.

      Wenn man sich mal daran gewöhnt hat, schreibt man sie auch automatisch schon. Oder aber die IDE sagt einem, dass man sie verwenden soll. Hierzu dann in den nächsten Teilen mehr 🙂

      • „Also ich finde die Yoda-Condition gut, aber nur für den Vergleich auf Gleichheit. Bei Vergleichen auf größer oder kleiner finde ich sie auch schwierig.“

        Inzwischen habe ich nachgelesen, dass diese Auslegung ganz im Sinne der WPCS ist.

        Mehr darüber wäre in einem der Yoda-Condition gewidmeten Beitrag, allenfalls mit einer Erklärung, warum sie in WPCS fast als absolute Norm und nicht als Empfehlung eingegangen ist, zu diskutieren.

        Ich freue mich jedenfalls auf deine weiteren Beiträge zum Thema WPCS

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert