Codificarea standardelor pentru WordPress [Ghid]

Motivul pentru care avem standarde de codificare la toate (nu doar pentru WordPress) este de a crearea unui mediu familiar pentru programatori lucrul la un proiect. WordPress în special cuprinde o mare varietate de produse. De la nucleul în sine la teme și plug-in-uri, este foarte mult să te uiți - și să te amesteci foarte mult.

Dacă fiecare își formulează codul în același mod, utilizează comentarii, același stil de documentare și așa mai departe, lucrul împreună devine mult mai ușor și curba de învățare de a se alătura unui nou proiect nu va fi la fel de abruptă.

Nevoia de coeziune în WordPress este amplificată de starea în care se află codul. WordPress nu urmărește o abordare strict orientată spre obiect și nu utilizează un model MVC. Proiectele care respectă orientările OOP și MVC fără excepție (precum Laravel) au consecvență și cele mai bune practici “copt înăuntru” datorită structurii lor.

WordPress este din păcate coaptă pentru codarea spaghetelor, adică a face tot ce vrei. Cele mai bune practici sunt dificil de aplicat pur și simplu pentru că produsele care folosesc cod rău pot funcționa la fel de bine (la suprafață).

Urmând WordPress Coding Standards, puteți învăța un pic despre ethosul de codare al WordPress, creați mai multe produse compatibile cu WordPress. arată comunitatea căreia ți-o pasă și te bate codul de înaltă calitate.

Mai multe despre Hongkiat.com:

10 cele mai grave cosmaruri pentru dezvoltatorii web
5 motive pentru care CSS ar putea fi cel mai greu limbaj al tuturor
30 programatori obișnuiți de reacție au când lucrurile merg greșit

Unele note cu privire la standarde

Standardele nu definesc bine și rău. S-ar putea să nu fiți de acord cu o regulă, de exemplu ar trebui folosite întotdeauna brațele, chiar dacă acestea nu sunt necesare. Scopul standardelor de codificare WordPress nu este de a decide dacă aveți dreptate sau rău, ci să decideți cum trebuie făcut în WordPress.

Standardele nu sunt supuse dezbaterii. Utilizarea standardelor nu este locul pentru a vă opune unui stil de indentare care nu vă place. Dacă ceva este în standardele de codificare, atunci faceți-o în felul acesta. Dezvoltatorii WordPress vă vor iubi pentru asta! Acestea fiind spuse, dacă nu sunteți de acord cu ceva de acolo, ridicați vocea și lăsați oamenii să știe. Este întotdeauna posibil să faci mai bine lucrurile, dar ar trebui să-ți schimbi stilul de codare doar dacă standardele permit acest lucru.

Consistența față de retenția anală. Dacă vă aflați în ultimele 10% din proiectul dvs. și tocmai ați descoperit că ați folosit convenția de numire incorectă pentru clase, nu treceți la jumătatea drumului. În opinia mea personală, aș citi mai degrabă ceva consecvent incorect decât ceva care este uneori corect și uneori nu. Puteți scrie întotdeauna un script pentru a schimba lucrurile dintr-o dată sau puteți citi codul la sfârșit.

Urmărirea standardelor este dificilă! Plasarea unei bretele pe aceeași linie cu funcția în locul unei linii de mai jos este destul de ușoară, chiar dacă sunteți obișnuit să apăsați înainte. Cu toate acestea, atunci când trebuie să vă gândiți la 100 de reguli mici, întregul proces devine un pic predispus la erori. În ciuda stării mele stricte în ceea ce privește respectarea standardelor, sunt la fel de vinovat ca oricine altcineva în a face greșeli. La sfârșitul zilei, indentarea incorectă nu este un păcat irevocabil. Încercați să respectați toate regulile, veți învăța totul în timp.

WordPress Coding Standards

În prezent, WordPress are patru ghiduri, unul pentru fiecare limbă folosită: PHP, HTML, Javascript și CSS. Acestea fac parte dintr-un corp mai larg de cunoștințe, Manualul principal al contribuitorilor. Trecerea prin tot ar lua ceva timp, așa că am subliniat câteva fragmente din cele patru limbi pe care le văd frecvent că oamenii se înșelă.

PHP

PHP este limba principală a WordPress și este un limbaj destul de slab tastat, ceea ce îl face să fie coaptă pentru reglementare.

Stiluri de brățară

Piesele de pornire trebuie plasate întotdeauna la capătul liniilor. Afirmațiile înrudite ar trebui să fie plasate pe aceeași linie ca și cea precedentă. Acest lucru este cel mai bine demonstrat cu un exemplu de cod:

dacă (condiție) // Do ceva elseif (condiție) // Do ceva altceva // Do Something

Utilizarea generoasă a spațiului

Eu nu sunt un fan al codului stricat (am o vedere neplăcută), așa că acesta este unul pe care îmi place în mod deosebit să îl impun. Spațiu după virgule, și pe ambele părți ale logic, comparaţie, şir și operatori de atribuire, după dacă, elseif, pentru, pentru fiecare și intrerupator declarații și așa mai departe.

Este mai ușor să spui unde nu ar trebui adăugate spații! Singura dată când nu ar trebui să adăugați spații este când typecasting sau referindu-se la matrice.

O excepție destul de confuză față de excepție sunt tablourile în care cheia array este o variabilă, în acest caz, utilizați un spațiu. Acest exemplu ar trebui să facă clar acest lucru:

funcția my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if null == $ complete_array) $ final_array = $ complete_array;  altceva $ key_1 = (integer) $ key_1; $ final_array [0] = 'aceasta'; $ final_array [$ key_1] = 'este'; $ final_array [$ cheie_2] = 'an'; $ final_array ['last'] = 'exemplu';  return $ final_array;

Convențiile de denumire

Acest lucru poate fi greu să vă obișnuiți, mai ales dacă veniți din medii diferite. Pe scurt:

Nume variabile ar trebui să fie Doar litere mici, cuvinte separate cu sublinieri
Numele claselor ar trebui să folosească cuvintele capitalizate separate de sublinieri. Acronime ar trebui să fie totul majuscule
constante ar trebui să fie toate majuscule, împărțit de sublinieri
Numele fișierelor ar trebui să fie Doar litere mici, separat de liniuțe

Conditii Yoda

Condițiile de scriere inversă decât cele obișnuite vor împiedica erorile de analiză. Se pare un pic ciudat, dar codul este mai bun.

dacă ('Daniel' === $ name) echo 'Scrieți articolul veți face';

HTML

HTML nu are multe reguli asociate cu acesta, aș putea să văd destul de mult pentru a face lucrurile mai modulare. Există doar cinci reguli pe care trebuie să le cunoașteți atunci când scrieți cod HTML:

Codul dvs. trebuie să fie validat împotriva validatorului W3C.
Etichetele HTML de auto-închidere trebuie să aibă exact un spațiu înainte de slash-ul înainte (aceasta este una pe care o urăsc personal, dar este o specificație W3C, nu doar un WordPress pet peeve)
Atributele și etichetele trebuie să fie minuscule. Singura excepție este atunci când valorile atributelor sunt destinate consumului uman, caz în care acestea ar trebui să fie tipizate în mod natural.
Toate atributele trebuie să aibă o valoare și trebuie să fie citate (scrierea nu este corect)
Indentarea ar trebui să fie realizată cu ajutorul unor file și ar trebui să urmeze o structură logică.

CSS

CSS este un alt limbaj scris cu litere mici, astfel încât să fie și multe de făcut aici. Chiar și așa, standardele merg destul de ușor pe codere.

selectori

Selectorii trebuie să fie calificați după cum este necesar, să fie citiți de om, să fie minuscule cu cuvintele separate cu liniuțe, iar selectorii de atribute ar trebui să utilizeze ghilimele duble. Iată un exemplu concis:

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

Ordine de proprietate

Standardele recunosc aici nevoia de spațiu personal deoarece nu prescriu o comandă specifică pentru regulile CSS. Ce ei do este că ar trebui să urmezi o structură semantică care are sens. Grupați proprietățile după relațiile lor sau grupați-le în ordine alfabetică, pur și simplu nu le scrie în mod aleatoriu.

Cea mai mare cauză a alegerii este “oh, de asemenea, trebuie să adăugați o marjă” și apoi continuați să o adăugați la partea de jos. Luați extra .3 secunde și adăugați regula în locul logic.

Afişa
poziţionarea
Modelul cutiei
Culori și tipografie
Alte

.profil-modal display: bloc; Poziția: absolută; stânga: 100px; top: 90px; fundal: # ff9900; culoare: #fff;

Formatarea valorilor

Acesta este un loc în care îmi place foarte mult să văd neconcordanțe. Dacă nu respectați liniile directoare, este mai bine decât să vedeți câteodată un spațiu înaintea valorii; uneori folosind stenograma, uneori nu; uneori, folosind unități pe valori 0, uneori nu, etc.

Formatul de valoare este destul de complex, dar ea vine în mod natural cu o anumită practică. Uitați-vă la ghidul exact din Codul pentru formatarea valorilor.

Javascript

Din experienta mea Javascript este cel mai predispus sa mearga peste tot. În timp ce mulți dezvoltatori cunosc o cantitate considerabilă de Javascript, au fost învățați treptat, ca o urmă după HTML, CSS și PHP. Când începeți cu o limbă nouă, faceți mai multe greșeli și dacă aceste greșeli nu cauzează erori fatale, ele pot deveni înrădăcinate în tine.

În multe cazuri, standardele se referă la o limită sau la o linie “dacă o linie nu este prea lungă”. Acest lucru se referă la Ghidul de stil jQuery care impune o Limita de 100 de caractere pe linii. Ghidul WordPress se bazează pe ghidul jQuery, așadar este o idee bună să oferiți și o citire.

virgulele

Aceasta este cea mai simplă regulă, dar este una care este adesea trecute cu vederea. Niciodata, omiteti punct si virgul doar pentru ca codul va functiona fara ea. Este pur și simplu neglijent.

crestarea

Tab-urile ar trebui să fie întotdeauna folosite pentru indentare. De asemenea, trebuie să indentați conținutul unei închideri chiar dacă conținutul unui întreg fișier este conținut într-unul. Nu sunt sigur de ce, dar închiderea neimpozată de nivel superior ma ajutat chiar înainte de a citi standardele.

Linii de rupere

Când spargeți șiruri lungi, rupeți întotdeauna linia după un operator, nu lăsați o variabilă agățată. Acest lucru face evident la prima vedere că linia este ruptă și nu ați uitat doar un punct și virgulă.

De asemenea, dacă o condiție este lungă, spargeți-o în mai multe linii și adăugați o filă în plus înainte. Aceasta arată foarte ciudat la ochii mei, dar separarea pe care o adaugă între condiție și corp este foarte vizibilă.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Această linie constă din cuvinte "+ n +", deci ar trebui defalcată după "+" un operator ";

Iterația jQuery

Conform standardului jQuery iterație (JQuery.each ()) ar trebui să fie utilizat numai pe obiecte jQuery. Ar trebui să utilizați elementul de bază pentru, pentru / în, in timp ce buclă în Javascript pentru iterarea față de alte colecții.

Concluzie

Există multe lucruri de observat și de urmărit și nu există nicio modalitate prin care cineva să poată aplica toate acestea dintr-o dată. Ar trebui să țineți codul cât mai aproape de standarde și să lucrați la urmărirea exactă a acestora.

In opinia mea consistența este cea mai importantă regulă. Este mai bine să faci în mod constant ceva incorect decât să comutați pe jumătate. Acest lucru este valabil mai ales în cazul practicilor de formatare, deoarece acestea nu afectează funcționalitatea codului dvs. și - în cea mai mare parte - pot fi schimbate cu ușurință mai târziu.

Urăsc un element al standardelor de codare, credeți că trebuie adăugat ceva? Anunțați-ne în comentarii!