Saubere WordPress Plugin und Theme Entwicklung

Hallo liebe WordPress-Welt, ich schenke dir meine composer.json, auf dass du bessere Plugins und Theme lieferst als bisher. Manch einer hat sich in seinem eigenen Code schon verlaufen oder wird immerzu von ThemeForest abgelehnt. Dabei lässt sich das ganz leicht verhindern.

Nun gut, dass hier ist eine etwas überladene Composer-Vorlage, aber lieber einmal richtig als 10 Mal angefasst und drin herum gefuscht:

 

An sich dürfte jeder Teil selbsterklärend sein, bis auf der (sehr) wichtige Part:

Behat

Mit „behat/behat“ wird hier ein Framework für Browsertests geladen, so dass das eigene Plugin oder die eigene Seite völlig automatisch von einem beliebigen Browser getestet werden kann. Damit es wirklich über die bekannten, wie Firefox, Chrome, Internet Explorer und Co läuft, sind noch zusätzliche Erweiterungen nötig (behat/mink und ähnlich benannte). Üblich sind dann zum Beispiel diese Anweisungen, welche der Browser auf magische Weise von selbst ausführt:

Als minimals Beispiel, das der Browser dann von allein mit der Seite interagiert und anschließend auch nachschaut, ob alles seine Richtigkeit hat.

phpDocumentor

Per „phpdocumentor/phpdocumentor“ wird ein Spielzeug für den Haupt-Entwickler installiert, das gleichzeitig eine große Hilfe für alle anderen Entwickler sein kann. Es durchforstet die PHP-Dateien vom Plugin nach DocComments, die in der Regel so aussehen können:

Dies würde zum Beispiel ein schönes Handbuch über die Verwendung von Shortcodes, Filtern, Klassen, Methoden, Funktionen oder Globalen liefern, welche alle über das Plugin definiert wurden.

phpmd

Per „phpmd/phpmd“ kann der Code nach Mist durchsucht werden, was ein häufiges Problem ist in vielen Plugins die es kostenlos bei WordPress gibt oder auch gekauft werden können. Zu oft sind dort komplexe Funktionen, ewig langer Code hinterlegt oder solche Sachen die es für andere schwer machen den Code zu verstehen:

Hier sehen wir, dass manche Stellen sehr komplex sind, Variablen nicht aussagekräftig genug oder mancher Code (z.B. das else) garnicht benötigt werden. Dies hindert nicht nur andere, den Code zu lesen und verstehen.
Der Urheber des Plugins wird sich bei seinem populären Plugin eines Tages ärgern, dass diese Dinge ihn daran hindern ein bestimmtes neues Feature einzubauen. Das Resultat ist ein Refactoring/Umschreiben der ganzen Aufmachung des Plugins, was nach dem Bereitstellen für andere und Ausliefern dann bei jedem WordPress zu ganz eigenen „komischen“ Fehlern führt. Das die Popularität dann weg ist, dürfte klar sein. Und ja, auch das passiert immer wieder bei den kostenlosen Plugins (selbst bei CF7 oder WP-Seo).

CodeSniffer

Der „squizlabs/php_codesniffer“ ist ein Tool, was ebenso schlechten Code erschnüffeln kann. Nicht aber im Sinne der Komplexität oder Wiederverwendbarkeit wie es phpmd könnte, sondern mehr ob die Coding Standards von WordPress eingehalten wurden. Dabei wird sehr darauf geachtet, dass Tabs statt Leerzeichen zum einrücken genutzt werden Variablen als lower Snake-Case geschrieben sind, Dateien aber nicht und vieles mehr:

Dies ist mehr Kunst und schönes Aussehen vom Code als Funktionalität. Dies ist nicht nur für OpenSource wichtig, damit jeder sich im Code „wohlfühlt“. Dank dem einheitlichen Bild, brauchen auch wir als Entwickler uns nicht mehr ärgern, in den Plugins und Themes der anderen durchzusteigen, welche oft konfusen und unordentlichen Code ausliefern. Dabei ist ordentlicher Code in IDEs (z.B. phpStorm, Netbeans oder eclipse) nur eine Tastenkombination entfern und kann mit jedem Commit sogar automatisch laufen.

Spread the word!

Wer ein schönes Plugin haben möchte, das lange lebt oder ein Theme das bei ThemeForest fast schon durchgewunken wird, der wird mit diesen Tools glücklich werden. All diese Tests sollten mindestens vor jedem Release einmal sein, um gute CodeQualität an die WordPress-Welt zu lierfern. Für mich ist es ein fester Bestandteil der eigenen Plugins geworden und einfach zu sehen, dass diese Tools meinen Code analysieren ohne zu meckern, bereichert um das Gefühl seine Zeit sinnvoll investiert zu haben und ein paar gute Zeilen geschrieben zu haben. Es gibt bereits ein paar wenige Entwickler, die diese Sachen beachten aber ich hoffe es werden noch ein paar mehr!

Hinterlasse einen Kommentar

*

1 comment

  1. Pingback: WordPress Coding Standards vs. PHP › shortcodes - Das Blog für WordPress-Entwickler

Nächster ArtikelRIPS - Sucht im Quelltext nach Sicherheitslücken