Verwenden der PSRs (im Vergleich zu den WordPress-Codierungsstandards)
An diesem Punkt weiß ich nicht, wie viele Artikel ich über die Bedeutung der WordPress-Codierungsstandards geschrieben habe (genug, um sie hier, hier und hier zu verlinken, schätze ich, was etwas ausmacht).
Aber nachdem ich genug Projekte für Kunden gemacht und mit Entwicklern gearbeitet habe, die viel klüger und vertrauter mit fortgeschrittenen Werkzeugen sind als ich, bin ich an einem Punkt angelangt, an dem ich mich dafür entscheide, PSRs in der WordPress-WordPress-Entwicklung zu verwenden.
Oh, das Drama, oder?
Aber im Ernst. Dafür gibt es Gründe, und es gibt Zeiten, in denen ich denke, dass die WordPress-Codierungsstandards immer noch verwendet werden sollten, aber ich werde schnell mehr davon überzeugt, dass beim Aufbau eines modernen Projekts auf WordPress modernere PHP-Tools verwendet werden sollten (was ich werde ich später kurz erwähnen).
Verwendung von PSRs in der WordPress-Entwicklung
Posts wie dieser geben oft Einblick in eine Debatte oder dramatische Reaktion innerhalb von WordPress, was weder meine Absicht noch etwas ist, das ich für notwendig halte. Um ehrlich zu sein, kenne ich eine ganze Reihe anderer Entwickler, die alle dies vor langer Zeit getan haben, darüber gesprochen haben, vorangekommen sind und weiterhin sowohl in ihrem Geschäft als auch in ihren Hobbyprojekten erfolgreich waren.
Aber angesichts der Tatsache, dass ich so viel über das eine gegen das andere gesprochen habe, dachte ich, dass es sich lohnt, meine Meinung darüber zu teilen, warum ich mich jetzt für diesen Wechsel entscheide, und die Gründe dafür.
1 Parität mit der PHP-Community
Im Laufe des letzten Jahres oder so, und wirklich allein in den letzten Monaten dieses Jahres, habe ich mich mehr daran gewöhnt:
- erfahrenere PHP-orientierte Entwicklerfreunde, die Tools unterstützen, die eine Übernahme der PSRs erwarten,
- die Verwendung von //@codingStandardsIgnoreStart und //@codingStandardsIgnoreEnd in meinem Code,
- benutzerdefinierte Regelsätze für meine Projekte basierend auf den Umgebungen, in denen sie bereitgestellt werden,
- und mehr.
Letztendlich geht es darum, die Parität (oder ein bisschen davon) mit der größeren PHP-Community im Allgemeinen aufrechtzuerhalten und gleichzeitig lesbaren, auf Standards basierenden Code auf WordPress zu schreiben. Und ich möchte auch einige andere Tools und neuere Versionen bestehender Tools verwenden (auf die ich später in diesem Beitrag eingehen werde).
2 Probleme mit modernen Umgebungen
Zum Zeitpunkt des Schreibens dieses Beitrags hat der PHP CodeSniffer (der zum Ausführen der WordPress Coding Standards erforderlich ist) die Version 3.0.2. Es gibt jedoch Kompatibilitätsprobleme mit PHPCS und mit den WordPress Coding Standards. Konkret :
Die neue Version von PHP CodeSniffer hat einige nette Features, führt aber Breaking Changes ein, was bedeutet, dass die WordPress-Codierungsstandards nicht kompatibel sind.
Um es klar zu sagen (und aufgrund der Natur von Software), es ist eine Frage der Zeit, bis es behoben ist. Wenn Sie jedoch an einer Codebasis arbeiten und Composer und die WordPress-Codierungsstandards verwenden, müssen Sie die PHP-CodeSniffer-Version explizit festlegen und nicht die aktuellste Version.
Darüber hinaus habe ich Probleme mit Kunden erlebt, bei denen meine Nichtübernahme der PSRs in der WordPress-Entwicklung zu einem merkwürdigen Verhalten bei der Bereitstellung von Code geführt hat. Vielleicht könnte man argumentieren, dass sie die Umgebung anpassen sollten, aber wenn sie daran arbeiten, den Menschen, die sie verwenden, die modernsten Tools zur Verfügung zu stellen, warum einen Rückschritt machen?
3 Kompatibilität mit modernen Tools
Schließlich gibt es eine Reihe moderner Tools, die ich nicht verwenden, geschweige denn lernen konnte, weil die Art der Versionierung unterstützt und was nicht.
Zum Beispiel haben wir GrumPHP in einem kürzlich durchgeführten Projekt verwendet, das eine Vielzahl von Tools unterstützt, aber wir konnten beispielsweise PHPMD nicht verwenden, da die PSRs nicht angenommen wurden. Soweit es mich betrifft:
- Ich möchte meine Fähigkeiten als Entwickler (und in diesem Zusammenhang als PHP-Entwickler) kontinuierlich verbessern,
- Mangelnde Unterstützung für modernere Tools bringt mich in eine Warteschleife, die ich sonst nicht erleben würde,
- Ich möchte weiterhin mit WordPress arbeiten, aber mit einem moderneren Workflow
Und im Moment entsteht durch die Nichtverwendung der PSRs eine Lücke zwischen dem, was der Rest der PHP-Community tut, und dem, was WordPress tut. Ich würde also gerne weitermachen und gleichzeitig an Projekten arbeiten, die ich zusätzlich zu Software verwende, die ich immer noch gerne verwende.
Was ist mit den WordPress-Codierungsstandards?
Was hat das also mit den WordPress Coding Standards und früheren Posts zu bedeuten? Nichts wirklich. So wie ich es sehe: Die WordPress Coding Standards sollten verwendet werden, wenn Sie an WordPress Core oder etwas arbeiten, das eng darin integriert werden soll.
Aber wenn Sie an etwas arbeiten, das auf WordPress aufsetzt oder WordPress als Grundlage verwendet, können Sie die PSRs in der WordPress-Entwicklung zusammen mit Tools verwenden, die dazu beitragen können, die Qualität der von Ihnen erstellten Codebasis zu verbessern.
Das ist zumindest für den Moment die Perspektive, die ich einnehmen werde. Ich bin gespannt, wie es sich in den nächsten Monaten entwickelt. Und wie für alles andere, was ich geteilt habe, werde ich die Aspekte dieser Umstellung teilen.