Grundlegende Codierungsstandards über PSR-1

Gestern habe ich kurz über eine Begründung für die Verwendung von PSRs im Vergleich zu den WordPress-Codierungsstandards und das Wann und Warum von beiden gesprochen. Aber das bedeutet nicht, dass es nicht ohne Verwirrungspunkte ist, besonders wenn Sie gerade erst damit anfangen, oder?

Damit meine ich: Angenommen, Sie arbeiten seit Jahren mit den WordPress-Codierungsstandards (weil ich das nachvollziehen kann) und jetzt gibt es diese ganzen neuen Regeln und Richtlinien, denen Sie folgen müssen. Aber es ist nicht so, als müssten einfach einige Leerzeichen geändert und Dateien umbenannt werden.

Es gibt weitere Punkte, die folgen müssen, und jeder wird in einer Zahl beschrieben, ganz wörtlich (PSR-1, PSR-2 usw.), wie etwas funktionieren sollte.

Was sind also einige problematische Bereiche, auf die wir als WordPress-Entwickler stoßen können, wenn es nur um die grundlegenden Codierungsstandards geht, wie sie in PSR-1 beschrieben sind?

Grundlegende Codierungsstandards (und Nebenwirkungen)

Ich habe nicht vor, jedes der Dokumente durchzugehen und zu wiederholen, was wir bereits lernen können, indem wir sie einfach lesen, aber ich denke, es spricht einiges dafür, etwas zu nehmen, das viele von uns entweder tun oder erleben, und zu sehen, wie sich dies im Inneren ändern könnte Kontext von WordPress.

Nehmen Sie zum Beispiel Nebenwirkungen aus dem Basic Coding Standard (oder PSR-1 ):

Eine Datei SOLLTE neue Symbole (Klassen, Funktionen, Konstanten usw.) deklarieren und keine anderen Nebeneffekte verursachen, oder sie SOLLTE Logik mit Nebeneffekten ausführen, aber NICHT beides.

Der Ausdruck „Nebenwirkungen” bedeutet die Ausführung von Logik, die nicht direkt mit der Deklaration von Klassen, Funktionen, Konstanten usw. zusammenhängt, sondern lediglich durch das Einschließen der Datei.

Ich persönlich halte den zweiten Satz für den Schlüssel zum Verständnis und möglichst zur Vermeidung von Seiteneffekten in unserem Code. Das heißt, alles, was unsere Klassen tun, sollte in sich geschlossen sein oder mit etwas zusammenhängen, das möglicherweise auf irgendeine Weise injiziert wurde.

Ungeachtet dessen sollte es nicht zu schwierig sein, Code zu finden, der einen Nebeneffekt einführt, und ihn zu bereinigen. Tatsächlich werde ich mich selbst als Beispiel verwenden.

Sehen Sie sich dieses spezielle Stück Code an :

Dieser Code stammt direkt von Toggle Admin Notices. Zugegeben, es ist einfach, und das Repository zeigt eine Notiz, wie es geändert werden kann. Es demonstriert dennoch den Punkt, oder?

Was ist die Lösung? Dies geschieht in Form von Autoloading (das auch in PSR-4 behandelt wird ). Was wäre also, wenn ich es umgestalten würde, damit es PSR-1 richtig folgt? Dann könnte eine Möglichkeit der Umgestaltung so aussehen :

Ist das ein tolles Beispiel? Wahrscheinlich nicht. Aber es geht um mehr als nur das Einbinden von Dateien. Das Einschließen dieser Dateien bedeutet, dass diese einzelne Datei eine Vielzahl von Nebenwirkungen einführt.

Das bedeutet, dass diese eine Datei allein für viel mehr als nur diese vier Codezeilen verantwortlich ist. Stellen Sie sich vor, Sie integrieren alles, was andere Dateien implementieren. An diesem Punkt wird es komplexer.

Nehmen Sie also diese Idee und verschieben Sie sie in ein viel größeres System, und Sie können sehen, wie und warum dies problematisch wäre.

Natürlich gibt es auch alternative Wege. Und das ist nur ein Beispiel. Auch selbstironisch. Es geht nicht so sehr darum, einen endgültigen Weg zu zeigen, wie dies zu tun ist, sondern darum, Gedanken darüber zu säen, wie wir Klassen entwerfen, planen, erstellen und integrieren.

Was ist mit Ansichten?

Wenn es um das Schreiben von Plugins geht, bin ich parteiisch dafür, das zu behandeln, was Benutzer als Ansichten sehen. Aber hier scheint es einen Haken zu geben: Es wird als schlechte Praxis angesehen, Dateien einzuschließen, da es Nebeneffekte einführt.

Wir wollen also keine Logik in unseren Klassen ausgeben, sondern auch die Präsentation von der Geschäftslogik trennen.

Was sollen wir tun?

Der Clou … ist, dass wir dafür objektorientierte Programmierung verwenden werden. Wir entwerfen eine Klasse, die HTML mit einer PHP-Vorlage generiert.

Dies wurde von jemand anderem ausführlich behandelt, und ich empfehle dringend, diesen speziellen Beitrag zu lesen, um die Idee von Nebenwirkungen zu verstehen, sie zu vermeiden und so weit wie möglich solide Praktiken zu integrieren.

…und Assets und zugehörige Dateien?

Ich weiß: Die Idee, sich von Nebenwirkungen zu entfernen (geschweige denn, sie zu identifizieren), kann am Anfang seltsam sein, besonders wenn Sie an bestimmte Dinge denken, die wir so lange gemacht haben.

Und es kann Fragen aufwerfen wie: Ist das Einbinden von JavaScript-Dateien oder CSS-Dateien falsch? Das ist wahrscheinlich ein Thema für einen anderen Beitrag. Denken Sie jedoch daran, dass es Kern-API-Funktionen gibt, die direkt damit zusammenhängen, und sie können Teil einer Klasse sein, die ausschließlich dafür verantwortlich ist.

Wenn der Zweck einer Klasse darin besteht, genau das und nur das zu tun, und dafür API-Funktionen verwendet, dann würde ich sagen, dass es wahrscheinlich in Ordnung ist.

Aber ich schweife vorerst davon ab (und vielleicht ist es ein Thema für die Kommentare oder wieder einen anderen Beitrag).

Halten Sie stattdessen Ihren Unterricht schlank und zielgerichtet. Sie sollten sich an die Vorgaben von PSR-1 halten und Dinge wie „[Deklaration] neuer Klassen, Funktionen, Konstanten usw.” vermeiden. und „[Ausführen] von Logik mit Nebeneffekten.”