A WordPress kódolási szabványai [Útmutató]

Az ok, hogy egyáltalán van kódolási szabványunk (nem csak a WordPress számára) hozzon létre egy ismerős környezetet a programozók számára egy projekten dolgozik. A WordPress különösen a termékek széles skáláját foglalja magában. A mag magától a témákig és a bővítményekig sok mindent meg kell nézni - és sokat kell keverni.

Ha mindenki ugyanolyan formátumban formázza kódját, megjegyzéseket, azonos dokumentációs stílusokat stb. Használ, az együttműködés sokkal könnyebbé válik, és az új projekthez való csatlakozás tanulási görbéje nem lesz olyan meredek.

A WordPress-ben a kohézió szükségességét növeli az az állam, amelyben a kódbázis áll. A WordPress nem követi szigorú objektumorientált megközelítést, és nem használ MVC mintát. Azok a projektek, amelyek kivétel nélkül az OOP és MVC iránymutatásokat követik (mint Laravel), konzisztensek és legjobb gyakorlatokkal rendelkeznek “sült” szerkezetük miatt.

A WordPress sajnos érett spagetti kódolásra, más néven csinálsz, amit akarsz. A legjobb gyakorlatokat nehezen lehet érvényesíteni, mert a rossz kódot alkalmazó termékek ugyanolyan jól működhetnek (a felületen).

A WordPress kódolási szabványok követésével egy kicsit megtudhatod a WordPress kódolási etoszkópját, több WordPress-kompatibilis terméket hozhatsz létre. mutasd meg azt a közösséget, amelyre törődsz, és magas minőségű kódot rendezsz.

További információ a Hongkiat.com oldalon:

10 legrosszabb rémálmok a webes fejlesztők számára
5 ok, amiért a CSS lehet az összes legnehezebb nyelve
30 Gyakori reakciók A programozóknak van valami, ami rosszul megy

Néhány megjegyzések a szabványokról

A szabványok nem határozzák meg a helyes és helyteleneket. Lehet, hogy nem értenek egyet a szabályokkal, például a zárójeleket mindig használják, még akkor is, ha nem szükségesek. A WordPress kódolási szabványok célja nem az, hogy eldöntsük, hogy helyes vagy rossz, hogy eldöntsük, hogyan kell ezt a WordPress-ben végrehajtani.

A szabványok nem vita tárgyát képezik. A szabványok használata nem az a hely, ahol egy tetszetős stílust ellenállhat. Ha valami a kódolási szabványokban van, akkor ezt tegye meg. WordPress fejlesztők szeretni fogják! Ez azt jelenti, hogy ha nem ért egyet azzal, hogy ott van, emelje fel a hangját, és tudassa az embereket. Mindig lehetőség van a dolgok jobb elvégzésére, de csak akkor módosíthatja a kódolási stílusát, ha a szabványok lehetővé teszik.

Konzisztencia az anális retentivitással szemben. Ha a projekt utolsó 10% -ában vagy, és most már rájött, hogy az osztályok helytelen elnevezési konvencióját használja, ne váltson középre. Személyes véleményem szerint inkább valamit következetesen helytelenül olvastam, mint amit néha helyesnek és néha nem. Mindig írhatsz egy parancsfájlt, hogy egy lépésben megváltoztassa a dolgokat, vagy a végén végigolvassa a kódot.

A következő szabványok nehézkesek! Egy rövid vonal elhelyezése ugyanazon a vonalon, mint a függvény egy alsó sorban, nagyon egyszerű, még akkor is, ha régebben szoktál belépni az előtte. Ha azonban 100 kis szabályra kell gondolkodnunk, az egész folyamat kicsit hibamentes lesz. Annak ellenére, hogy szigorú álláspontom van a következő szabványok iránt, olyan bűnös vagyok, mint bárki más, aki hibákat követett el. A nap végén a helytelen bevágás nem visszavonhatatlan bűn. Próbáld meg a lehető legjobban követni az összes szabályt, mindent időben megtanulsz.

WordPress kódolási szabványok

Jelenleg a WordPress négy útmutatókkal rendelkezik, amelyek közül az egyik a főbb nyelvek közül: PHP, HTML, Javascript és CSS. Ezek egy nagyobb tudásrész, a Core Contributor Handbook részét képezik. A mindent áthaladva egy darabig eltarthatnék, ezért kiemeltem néhány részletet a négy nyelv közül, amelyeket gyakran látok rosszul.

PHP

A PHP a WordPress fő nyelve, és egy elég lazán beírt nyelv, amely éretté teszi a szabályozást.

Brace stílusok

Az indító zárójeleket mindig a vonalak végén kell elhelyezni. A kapcsolódó állításokat ugyanazon a soron kell elhelyezni, mint az előző zárójel. Ezt legjobban egy kódpélda mutatja be:

if (feltétel) // Valamit otherif (feltétel) // Valamit más // Csinálj valamit

Nagylelkű térhasználat

Nem vagyok rajongó a szaggatott kódból (rossz látásom van), ezért ezt különösen szeretném érvényesíteni. Helyezzen be tereket vessző, és mindkét oldalán logikus, összehasonlítás, húr és hozzárendelési operátorok, után ha, elseif, mert, az egyes és kapcsoló nyilatkozatok és így tovább.

Könnyebb megmondani, hogy a tereket nem szabad hozzáadni! Az egyetlen alkalom, amikor nem kell teret adnod, amikor typecasting vagy hivatkozási tömbök.

A kivétel egy meglehetősen zavaró kivétel a tömbök, ahol a A tömb kulcs változó, Ebben az esetben használjon helyet. Ez a példa ezt egyértelművé teszi:

funkció my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  más $ key_1 = (egész szám) $ key_1; $ final_array [0] = 'ez'; $ final_array [$ key_1] = 'van'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'példa';  vissza a $ final_array;

Megnevezési egyezmények

Ez nehéz lehet megszokni, különösen, ha különböző környezetből származik. Dióhéjban:

Változó nevek kellene minden kisbetű, a szavak aláhúzással elválasztott szavak
Osztálynevek kell használni nagybetűs szavak aláhúzással elválasztva. mozaikszavak mindennek kell lennie nagybetűs
állandók kellene minden nagybetű, aláhúzással
Fájlnevek kellene minden kisbetű, szétválasztható

Yoda feltételek

A feltételeket más módon fordítva írja le, hogy megakadályozza a hibakeresést. Egy kicsit furcsa, de jobb kód.

ha ("Daniel" === $ név) echo "Írj cikket, amit akarsz";

HTML

A HTML-nek nincs sok olyan szabálya, amelyhez hozzátartozik, elég sok dolgot tudok felmutatni, hogy a dolgokat modulárisabbá tegyem. Csak öt szabály van, amit tudnia kell a HTML írásakor:

A kódnak érvényesítenie kell a W3C érvényesítőt.
Az önzáró HTML-címkéknek pontosan egy szóközzel kell rendelkezniük az előretekerés előtt (ez egy személyesen utálom, de ez egy W3C-specifikáció, nem csak egy WordPress-kedvenc)
Az attribútumoknak és a címkéknek kisbetűnek kell lenniük. Az egyetlen kivétel az, amikor az attribútumértékeket emberi fogyasztásra szánják, amely esetben ezeket természetesen kell gépelni.
Minden attribútumnak rendelkeznie kell egy értékkel, és idézni kell (írás nem helyes)
A bemetszést a fülek segítségével kell elérni, és logikai struktúrát kell követni.

CSS

A CSS egy másik lazán beírt nyelv, így itt is rengeteg munka szükséges. Mégis, a szabványok nagyon egyszerűek a kódolókon.

Szelektorok

A kiválasztóknak szükség szerint megfelelőnek kell lenniük, emberileg olvashatóknak kell lenniük, minden kisbetűvel, szavakkal elválasztott szavakkal, és az attribútumválasztóknak idézőjeleket kell használniuk. Íme egy tömör példa:

bemenet [type = "text"], bemenet [type = "password"], .name-field background: # f1f1f1;

Szállásfoglalás

A szabványok felismerik a személyes helyek szükségességét, mivel nem írnak elő külön CSS szabályokat. Mi az csinál azt mondják, hogy szemantikai struktúrát kell követnie van értelme. Csoportosítsa a tulajdonságokat a kapcsolataik alapján, vagy csoportosítsa őket ábécé szerint, csak ne írd ki őket véletlenszerűen.

A véletlenszerűség legnagyobb oka a “ó, hozzá kell adnom egy margót is” majd folytassa az alsó rész hozzáadásához. Vegye ki az extra 0,3 másodpercet, és adja hozzá a szabályt a logikai helyre.

Kijelző
Positioning
Box modell
Színek és tipográfia
Más

.profil-modális kijelző: blokk; pozíció: abszolút; left: 100px; top: 90px; háttér: # ff9900; szín: #fff;

Értékformázás

Ez egy olyan hely, ahol különösen utálom a következetlenségeket. Ha nem követi az iránymutatásokat, akkor ez még mindig jobb, mintha néha helyet látna az érték előtt; néha rövidítéssel, néha nem; néha 0 értékű egységet használ, néha nem stb.

Az értékformázás meglehetősen összetett, de természetesen valamilyen gyakorlattal jön. Tekintse meg a Codex-ban található pontos útmutatást az értékek formázására.

Javascript

Tapasztalatom szerint a Javascript a leginkább hajlamos az egész helyre. Míg sok fejlesztő tud egy jelentős mennyiségű Javascript-t, amit fokozatosan megtanultak, mint egy HTML, CSS és PHP utólagos gondolatát. Amikor éppen egy új nyelvvel kezdesz, sokkal több hibát csinálsz, és ha ezek a hibák nem okoznak végzetes hibákat, akkor belekeveredhetnek magadba.

Sok esetben a szabványok egy vonalhatárra vagy állapotra vonatkoznak “ha egy vonal nem túl hosszú”. Ez a jQuery Style Guide-ra utal, amely a 100 karakteres korlátozás vonalakon. A WordPress útmutató a jQuery útmutatón alapul, ezért jó ötlet, hogy ezt is olvasd el.

pontosvessző

Ez a legegyszerűbb szabály, de gyakran figyelmen kívül hagyja azt. Soha, soha ne hagyd ki a pontosvesszőt csak azért, mert a kódod nélkül fog működni. Csak hanyag.

behúzása

A füleket mindig a bemélyedéshez kell használni. A zárás tartalmát még akkor is be kell illesztenie, ha egy egész fájl tartalma egyben van. Nem vagyok biztos benne, hogy miért, de a nem szabadalmaztatott felső szintű bezárás még a szabványok elolvasása előtt hibázott.

Törésvonalak

Hosszú karakterláncok törésekor mindig szakítsa meg a vonalat a kezelő után, ne hagyj változót lógni. Ez első pillantásra nyilvánvalóvá teszi, hogy a vonal megszakadt, és nem felejtette el a pontosvesszőt.

Továbbá, ha egy feltétel hosszú, tegye meg több sorba, és adjon hozzá egy extra lapot előtte. Ez nagyon furcsa a szememre nézve, de az elkülönítés, amit hozzáad az állapot és a test között, nagyon jól látható.

if (firstCondition () &&c secondCondition () && third harmadik feltétel ()) var html = 'Ez a sor' + n + 'szavakból áll, így azt a' + 'operátor után kell bontani;

jQuery Iteráció

A jQuery iteráció szabványai szerint (JQuery.each ()) csak a jQuery objektumokon használható. Használja az alapszintet mert, be, míg hurkok a Javascript-ben más gyűjtemények felett.

Következtetés

Sok figyelemre méltó és nyomon követhető, és nincs mód arra, hogy valaki mindezt egy időben alkalmazza. A kódot a lehető legközelebb kell tartania a szabványokhoz, és pontosan követnie kell őket.

Szerintem a következetesség a legfontosabb szabály. Jobb, ha következetesen tegyünk valamit helytelenül, mint a félúton. Ez különösen igaz a formázási gyakorlatokra, mivel ezek nem befolyásolják kódja funkcionalitását és - nagyrészt - később könnyen cserélhető.

Utálod a kódolási szabványok egyik elemeit, szerinted valamit hozzá kell adni? Tájékoztassa velünk a megjegyzéseket!