WordPress Coding Standards vs. PHP

Einmal die WordPress Coding-Standards durchgelesen, macht es natürlich Spaß diese zu verfolgen und viel besser mit anderen WordPress-Entwicklern da draußen sich auszutauschen und deren Code zu verstehen. Aber warum ist das so weit von PHP weg? Ist es das auch von HTML?

Coding-Standards werden verfolgt, damit der Quelltext ein einheitliches Bild von sich gibt. So können viele Entwickler zusammenarbeiten und eine homogene Qualität erzielen. Ein fremdes Plugin oder Theme zu verstehen ist auch viel einfacher – einen Beitrag hierzu hatten wir bereits: Saubere WordPress Plugin und Theme Entwicklung .

PHP

Für PHP haben sich insbesondere die Macher überlegt ein paar Richtlinien zu formulieren, die allesamt unter https://make.wordpress.org/core/handbook/coding-standards/php/ zu finden sind. Für die damalige Zeit sicherlich gut und eine gern gesehene Maßnahme. Außer man betrachtet die folgenden Dinge:

Der „Brace Style“ besagt, dass die geschwungene Klammer hinter die Kontroll-Struktur kommt oder hinter die Funktion. In einer neuen Zeile ist sie nicht nur nützlicher, sondern würde auch vielen anderen Standards folgen wie zum Beispiel dem PHP-Kern selbst.

 

Die „Naming Conventions“ sind teilweise total daneben in SnakeCase postuliert für Funktionen / Methoden und Klassen, was niemals eingehalten werden kann sobald PHP-interne Klassen und deren Methoden verwendet werden und auch die Dateinamen vom PHP-Kern selbst dem entgegenstehen. Eine altbackene Regel, die heute nur noch für einfache Funktionen gilt.

 

Auch wenn das untersagen von „Clever Code“ toll ist, stellt sich die Frage warum dann die ebenso schwer lesbaren „Ternary Operator“ geduldet werden.

 

Wie schreibe ich namespaces, traits und alles was PHP neues zu bieten hat? Dürfen einfache Arrays geschrieben werden oder sollen es noch die überholten sein?

 

WordPress hat auch gute Vorschläge

Das „Space Usage“ sorgt zwar für sehr lange Zeilen, lockert den Code allerdings etwas auf und macht ihn für einen schnellen Blick lesbarer.

 

Shorthand PHP Tags“ machen es leichter PHTML zu lesen, allerdings ist das nicht immer aktiviert auf jedem Server und wird daher zurecht „verboten“.

 

Etwas weniger fehleranfällig wird der Quelltext durch die „Yoda Conditions„.

 

Der „nerdige“, gern gemachte „Clever Code“ mit all seinen Abkürzungen wird grundsätzlich untersagt – was es für Neulinge und nicht so versierte einfacher macht.

 

Alles in allem scheinen die Vorgaben nur veraltet zu sein. Diese in einem Schlag auf den aktuellen Stand zu bringen ist schwer machbar, da die WordPress-Welt sich nicht einfach so ändern lässt. Aber ein paar Erweiterungen (namespaces bitte!) wären schon von Vorteil.

Hinterlasse einen Kommentar

*

Nächster ArtikelWordPress Administrator über SQL anlegen