Kodierungsstandards für WordPress [Guide]

Der Grund dafür, dass wir überhaupt Codierungsstandards haben (nicht nur für WordPress), liegt in zu Erstellen Sie eine vertraute Umgebung für Programmierer an einem Projekt arbeiten. Insbesondere WordPress umfasst eine Vielzahl von Produkten. Vom Kern selbst bis zu Themes und Plugins gibt es viel zu sehen - und vieles, worüber man sich mischen kann.

Wenn alle ihren Code auf dieselbe Weise formatieren, Kommentare verwenden, den gleichen Dokumentationsstil verwenden, wird die Zusammenarbeit um einiges einfacher, und die Lernkurve für den Beitritt zu einem neuen Projekt ist nicht so steil.

Das Bedürfnis nach Kohäsion in WordPress wird um den Zustand erhöht, in dem sich die Codebase befindet. WordPress folgt keinem strengen objektorientierten Ansatz und verwendet kein MVC-Muster. Projekte, die ausnahmslos einer OOP- und MVC-Richtlinie folgen (wie Laravel), sind konsistent und bewährte Verfahren “gebacken” aufgrund ihrer Struktur.

WordPress ist leider reif für die Spaghetti-Codierung was immer du willst. Best Practices sind nur schwer durchzusetzen, da Produkte, die fehlerhaften Code verwenden, möglicherweise genauso gut funktionieren (oberflächlich)..

Wenn Sie die WordPress-Codierungsstandards befolgen, können Sie etwas über das Codierethos von WordPress lernen und weitere WordPress-kompatible Produkte erstellen. Zeigen Sie der Community, dass Sie sich interessieren, und Sie kämpfen mit qualitativ hochwertigem Code.

Mehr auf Hongkiat.com:

10 schlimmste Albträume für Webentwickler
5 Gründe, warum CSS die härteste Sprache von allen sein könnte
30 Häufige Reaktionen von Programmierern, wenn etwas schief läuft

Einige Hinweise zu den Standards

Die Standards definieren nicht richtig und falsch. Sie können einer Regel nicht zustimmen. Beispielsweise sollten immer geschweifte Klammern verwendet werden, auch wenn sie nicht benötigt werden. Der Zweck der WordPress-Codierungsstandards besteht nicht darin, zu entscheiden, ob Sie richtig oder falsch sind, sondern zu entscheiden, wie dies in WordPress geschehen soll.

Die Standards stehen nicht zur Debatte. Die Verwendung der Standards ist nicht der Ort, um sich gegen einen Eindrucksstil zu wehren, den Sie nicht mögen. Wenn etwas in den Kodierungsstandards enthalten ist, dann machen Sie es so. WordPress-Entwickler werden dich dafür lieben! Das heißt, wenn Sie mit etwas nicht einverstanden sind, erheben Sie Ihre Stimme und informieren Sie die Leute. Es ist immer möglich, die Dinge besser zu machen, aber Sie sollten Ihren Kodierstil nur ändern, wenn die Standards dies zulassen.

Konsistenz über anale Remanenz. Wenn Sie sich in den letzten 10% Ihres Projekts befinden und gerade festgestellt haben, dass Sie die falsche Namenskonvention für Klassen verwendet haben, wechseln Sie nicht in der Mitte. Meiner Meinung nach würde ich eher etwas Falsches lesen als etwas, das manchmal richtig ist und manchmal nicht. Sie können jederzeit ein Skript schreiben, um die Dinge auf einmal zu ändern, oder Ihren Code am Ende durchlesen.

Standards einzuhalten ist schwierig! Das Platzieren einer Klammer in derselben Zeile wie in der Funktion anstelle einer Zeile darunter ist ziemlich einfach, selbst wenn Sie vorher die Eingabetaste drücken. Wenn Sie jedoch über 100 kleine Regeln nachdenken müssen, wird der gesamte Prozess etwas fehleranfällig. Trotz meiner strengen Haltung, Standards einzuhalten, bin ich genauso schuldig wie alle anderen, Fehler zu machen. Am Ende des Tages ist eine falsche Einrückung keine unwiderrufliche Sünde. Versuchen Sie Ihr Bestes, um alle Regeln zu befolgen, Sie werden alles rechtzeitig lernen.

WordPress-Codierungsstandards

Derzeit gibt es in WordPress vier Handbücher, eine für jede verwendete Hauptsprache: PHP, HTML, Javascript und CSS. Sie bilden einen Teil eines größeren Wissensbündels, des Core Contributor Handbook. Alles durchzugehen würde eine Weile dauern, daher habe ich einige Ausschnitte aus den vier Sprachen hervorgehoben, bei denen ich häufig sehe, dass die Leute falsch laufen.

PHP

PHP ist die Hauptsprache von WordPress und ist eine recht locker typisierte Sprache, die es für die Regulierung reif macht.

Brace Styles

Anfangsklammern sollten immer am Zeilenende stehen. Verwandte Anweisungen sollten in derselben Zeile wie die vorherige schließende Klammer stehen. Dies wird am besten anhand eines Codebeispiels demonstriert:

if (Bedingung) // etwas tun elseif (Bedingung) // etwas tun else // etwas tun

Großzügige Speicherplatznutzung

Ich bin kein Fan von zusammengedrücktem Code (ich habe ein schlechtes Sehvermögen), daher ist es einer, den ich besonders gerne durchsetze. Leerzeichen nach setzen Kommas, und auf beiden Seiten von logisch, Vergleich, Schnur und Zuweisungsoperatoren, nach dem ob, elseif, zum, für jeden und Schalter Aussagen und so weiter.

Es ist einfacher zu sagen, wo Leerzeichen nicht hinzugefügt werden sollten! Das einzige Mal, wenn Sie keine Leerzeichen hinzufügen sollten, ist wann typecasting oder Referenzieren von Arrays.

Eine eher verwirrende Ausnahme von der Ausnahme sind Arrays, in denen das Feldschlüssel ist eine Variable, Verwenden Sie in diesem Fall ein Leerzeichen. Dieses Beispiel sollte dies deutlich machen:

Funktion my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar')) if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (ganze Zahl) $ key_1; $ final_array [0] = 'this'; $ final_array [$ key_1] = 'ist'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example';  return $ final_array;

Regeln der Namensgebung

Dies kann schwer zu gewöhnen sein, besonders wenn Sie aus verschiedenen Umgebungen kommen. In einer Nussschale:

Variablennamen sollte sein alles klein geschrieben, Wörter mit Unterstrichen getrennt
Klassennamen sollte nutzen großgeschriebene Wörter durch Unterstriche getrennt. Akronyme sollte alles sein Großbuchstaben
Konstanten sollte sein alles in großbuchstaben, gespickt von Unterstrichen
Dateinamen sollte sein alles klein geschrieben, mit Bindestrichen getrennt

Yoda-Bedingungen

Wenn Sie Bedingungen anders herum schreiben, als Sie es gewohnt sind, werden Fehler beim Analysieren vermieden. Es sieht ein bisschen komisch aus, aber es ist besser Code.

if ('Daniel' === $ name) echo 'Artikel schreiben, den Sie wollen';

HTML

HTML hat nicht so viele Regeln, ich könnte mir ziemlich viel einfallen lassen, um die Dinge modularer zu gestalten. Es gibt nur fünf Regeln, die Sie beim Schreiben von HTML kennen müssen:

Ihr Code muss gegen den W3C-Validator überprüft werden.
Selbstschließende HTML-Tags müssen genau ein Leerzeichen vor dem Schrägstrich enthalten (dies ist etwas, das ich persönlich hasse, aber es handelt sich um eine W3C-Spezifikation und nicht nur um ein WordPress-Pet).
Attribute und Tags müssen alle Kleinbuchstaben sein. Die einzige Ausnahme ist, wenn Attributwerte für den menschlichen Verzehr bestimmt sind. In diesem Fall sollten sie auf natürliche Weise eingegeben werden.
Alle Attribute müssen einen Wert haben und in Anführungszeichen gesetzt werden das ist nicht richtig)
Die Einrückung sollte mithilfe von Registerkarten erfolgen und der logischen Struktur folgen.

CSS

CSS ist eine andere locker getippte Sprache, daher gibt es auch hier viel zu tun. Trotzdem sind die Standards für Codierer ziemlich einfach.

Selektoren

Selektoren sollten so qualifiziert wie nötig sein, menschlich lesbar sein, alle Kleinbuchstaben mit durch Bindestriche getrennten Wörtern sein, und Attributselektoren sollten doppelte Anführungszeichen verwenden. Hier ein kurzes Beispiel:

Eingabe [Typ = "Text"], Eingabe [Typ = "Passwort"], .name-Feld Hintergrund: # f1f1f1;

Eigentumsordnung

Die Standards erkennen den Bedarf an persönlichem Raum an, da sie keine bestimmte Reihenfolge für CSS-Regeln vorschreiben. Was sie tun sagen, dass Sie einer semantischen Struktur folgen sollten macht Sinn. Gruppieren Sie Eigenschaften nach ihren Beziehungen oder gruppieren Sie sie alphabetisch, schreibe sie einfach nicht zufällig aus.

Die größte Ursache für Zufälligkeit ist die “Oh, ich muss auch eine Marge hinzufügen” und dann fahren Sie fort, um es unten hinzuzufügen. Nehmen Sie die zusätzlichen 0,3 Sekunden und fügen Sie die Regel an der logischen Stelle hinzu.

Anzeige
Positionierung
Box-Modell
Farben und Typografie
Andere

.Profil-Modal Anzeige: Block; Position: absolut; links: 100px; oben: 90px; Hintergrund: # ff9900; Farbe: #fff;

Formatierung von Werten

Dies ist ein Ort, an dem ich es besonders hasse, Inkonsistenzen zu sehen. Wenn Sie die Richtlinien nicht befolgen, ist das immer noch besser als manchmal vor dem Wert ein Leerzeichen zu sehen. manchmal mit Kurzschrift, manchmal nicht; manchmal mit Einheiten für 0 Werte, manchmal nicht usw.

Die Formatierung von Werten ist jedoch ziemlich komplex es kommt natürlich mit etwas Übung. Sehen Sie sich die genaue Anleitung im Codex zur Formatierung Ihrer Werte an.

Javascript

Nach meiner Erfahrung neigt Javascript am meisten dazu, überall hin zu gehen. Während viele Entwickler eine beträchtliche Menge an Javascript kennen, wurde sie nach und nach als HTML, CSS und PHP gelernt. Wenn Sie gerade erst mit einer neuen Sprache beginnen, machen Sie viel mehr Fehler und wenn diese Fehler keine fatalen Fehler verursachen, können sie in Ihnen verwurzelt sein.

In vielen Fällen beziehen sich die Standards auf eine Liniengrenze oder einen Zustand “wenn eine Zeile nicht zu lang ist”. Dies bezieht sich auf den jQuery Style Guide, der a auferlegt Zeilenlimit von 100 Zeichen. Das WordPress-Handbuch basiert auf dem jQuery-Handbuch. Daher ist es eine gute Idee, dies auch zu lesen.

Semikolons

Dies ist die einfachste Regel, die jedoch häufig übersehen wird. Lassen Sie niemals ein Semikolon aus, nur weil Ihr Code ohne es funktioniert. Es ist nur schlampig.

Einrücken

Zum Einrücken sollten immer Tabulatoren verwendet werden. Sie sollten auch den Inhalt eines Abschlusses einrücken, auch wenn der Inhalt einer ganzen Datei in einer Datei enthalten ist. Ich bin mir nicht sicher, warum, aber der oberste Verschluss auf der obersten Ebene hat mich gestört, noch bevor ich die Standards gelesen habe.

Linien brechen

Wenn Sie lange Zeichenfolgen brechen, brechen Sie die Zeile immer nach einem Operator, Lassen Sie keine Variable herum. Dies macht auf den ersten Blick offensichtlich, dass die Linie unterbrochen ist und Sie kein Semikolon vergessen haben.

Wenn eine Bedingung lang ist, teilen Sie sie in mehrere Zeilen auf und fügen Sie eine zusätzliche Registerkarte hinzu. Dieses sieht für meine Augen sehr seltsam aus, aber die Trennung, die es zwischen dem Zustand und dem Körper hinzufügt, ist sehr sichtbar.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Diese Zeile besteht aus' + n + 'Wörtern und sollte daher nach' + 'einem Operator' abgebrochen werden.

jQuery-Iteration

Gemäß den Standards jQuery-Iteration (jQuery.each ()) sollte nur für jQuery-Objekte verwendet werden. Sie sollten Basic verwenden zum, für in, während Schleifen in Javascript zum Durchlaufen anderer Sammlungen.

Fazit

Es gibt viel zu beachten und zu verfolgen, und niemand kann all dies auf einmal anwenden. Sie sollten Ihren Code so nah wie möglich an die Standards halten und daran arbeiten, sie genau zu befolgen.

Meiner Meinung nach Konsistenz ist die wichtigste Regel. Es ist besser, konsequent etwas falsch zu tun, als auf halbem Weg zu wechseln. Dies gilt insbesondere für Formatierungspraktiken, da diese die Funktionalität Ihres Codes nicht beeinträchtigen und - größtenteils - davon betroffen sind - kann später einfach stapelweise geändert werden.

Hassen Sie ein Element der Kodierungsstandards? Denken Sie, dass etwas hinzugefügt werden sollte? Lass es uns in den Kommentaren wissen!