WordPressi kodeerimisstandardid [Guide]

Põhjus, miks meil üldse on olemas kodeerimisstandardid (mitte ainult WordPress), on luua programmeerijatele tuttav keskkond projekti kallal. WordPress hõlmab eelkõige mitmesuguseid tooteid. Südamikust kuni teemadeni ja pluginateni on palju vaadata - ja palju segada.

Kui kõik vormindavad oma koodi samamoodi, kasutab kommentaare, sama laadi dokumente ja nii edasi, töötamine koos muutub palju lihtsamaks ja uue projektiga ühinemise õpikõver ei ole nii järsk.

WordPressis vajaliku ühtekuuluvuse vajadust suurendab see kood, kus koodibaas on. WordPress ei järgi ranget objektorienteeritud lähenemist ega kasuta MVC mustrit. Projektidel, mis järgivad eranditult OOP- ja MVC-suuniseid (nagu Laravel), on järjepidevus ja parimad tavad “küpsetatud” nende struktuuri tõttu.

WordPress on kahjuks spagetide kodeerimiseks küps, nimega tehes seda, mida sa tahad. Parimaid tavasid on raske rakendada lihtsalt seetõttu, et halva koodi kasutavad tooted võivad töötada sama hästi (pinnal).

Järgides WordPressi kodeerimisstandardeid, saate mõnevõrra õppida WordPressi kodeerimise eetost, luua rohkem WordPressiga ühilduvaid tooteid. näidake kogukonnale, keda sa hoolid, ja kostad kõrge kvaliteediga koodi.

Veel Hongkiat.com lehelt:

10 halvimat luupainajat veebiarendajatele
5 põhjust, miks CSS võiks olla kõige raskem keel
30 Ühised reaktsioonid Programmeerijatel on kui asjad lähevad valesti

Mõned märkused standardite kohta

Standardid ei määratle õigeid ja valesid. Te võite reegliga mitte nõustuda, näiteks tuleks alati kasutada traksid, isegi kui neid pole vaja. WordPressi kodeerimisstandardite eesmärk ei ole otsustada, kas teil on õigus või vale, otsustada, kuidas seda WordPressis teha.

Standardid ei ole aruteluks. Standardite kasutamine ei ole koht, kus te ei taha statiivi vastu võtta. Kui midagi on kodeerimisstandardites, siis tehke seda nii. WordPressi arendajad armastavad sind selle eest! See tähendab, et kui te midagi ei nõustu, tõstke oma häält ja andke inimestele teada. Alati on võimalik asju paremini teha, kuid oma kodeerimisstiili tuleks muuta ainult siis, kui standardid seda lubavad.

Järjepidevus anal analüüsi suhtes. Kui olete viimase 10% oma projektist ja olete just avastanud, et olete kasutanud klasside vale nimetuskonventsiooni, ärge lülitage keskmist. Minu isiklikul arvamusel loeksin pigem midagi järjekindlalt vale kui midagi, mis on mõnikord õige ja mõnikord mitte. Teil on alati võimalik kirjutada skript, et asju ühekordselt muuta või oma koodi lõpus lugeda.

Järgmised standardid on keerulised! Sulgurite paigutamine samale reale kui funktsioon allpool olevale reale on üsna lihtne, isegi kui oled harjunud eelnevalt lööma. Siiski, kui sa pead mõtlema 100 väikesele reeglile, muutub kogu protsess natuke veatundlikuks. Hoolimata minu rangetest seisukohtadest järgmiste standardite suhtes, olen ma nii süüdi kui keegi teine vigade tegemisel. Päeva lõpus ei ole ebaõige sisenemine tühistamatu patt. Proovige oma eeskirju järgida, sa õpid kõike õigeaegselt.

WordPressi kodeerimisstandardid

Praegu on WordPressil neli juhendit, üks iga kasutatava keele jaoks: PHP, HTML, Javascript ja CSS. Need moodustavad osa suuremast teadmiste kogumist, põhilisest toetaja käsiraamatust. Kõike läbides kulub aega, nii et olen esile toonud mõned väljavõtted neljast keelest, mida ma tihti näen, et inimesed eksivad.

PHP

PHP on WordPressi peamine keel ja see on üsna lõdvalt kirjutatud keel, mis muudab selle küpseks reguleerimiseks.

Trakside stiilid

Alustavad traksid tuleb alati paigutada joonte lõpus. Seotud avaldused tuleks paigutada samale joonele nagu eelmine sulgemisliides. Seda on kõige parem näidata koodide näitel:

kui (tingimus) // Kas midagi elseif (tingimus) // Kas midagi muul // Kas midagi

Suurepärane ruumikasutus

Ma ei ole fikseeritud koodi fänn (mul on halb nägemine), nii et see on mulle eriti meeldiv jõustamine. Pane tühikuid komadega, ja mõlemal pool loogiline, võrdlus, string ja loovutamise operaatorid, pärast seda kui, elseif, jaoks, igaühele ja lüliti avaldused ja nii edasi.

On lihtsam öelda, kus ruume ei tohiks lisada! Ainus kord, kui sa ei peaks tühikuid lisama, siis millal typecasting või viitamise massiivid.

Üsna segane erand erandiks on massiivid, kus massiivi võti on muutuja, sellisel juhul kasutage ruumi. See näide peaks selle selgeks tegema:

funktsiooni my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (täisarv) $ key_1; $ final_array [0] = 'see'; $ final_array [$ key_1] = 'on'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'näide';  tagasi $ final_array;

Nimetavad konventsioonid

See võib olla raske harjuda, eriti kui sa tuled erinevatest keskkondadest. Lühidalt:

Muutuvad nimed peaks olema kõik väiketähti, sõnad, mis on eraldatud allajoonidega
Klasside nimed peaks kasutama suured sõnad eraldatud alakriipsudega. Akronüümid peaks olema kõik suured
Konstantid peaks olema kõik suured, allakriipsutatud
Failide nimed peaks olema kõik väiketähti, eraldatud kriipsudega

Yoda tingimused

Tingimuste kirjutamine teisiti kui olete harjunud, et vältida vigade analüüsimist. Tundub natuke imelik, kuid see on parem kood.

kui ('Daniel' === $ nimi) echo 'Kirjuta artikkel, mida tahate';

HTML

HTML-il ei ole selliseid reegleid, mis oleksid sellega seotud, ma võiksin tulla üsna palju, et asju modulaarsemaks muuta. HTML-i kirjutamisel on vaja ainult viit reeglit:

Teie kood peab valideerima W3C vastu.
Enesesulguvad HTML-sildid peavad enne edasisuunalist kaldkriipsu olema täpselt üks ruum (see on üks, mida ma isiklikult vihkan, kuid see on W3C spetsifikatsioon, mitte ainult WordPress lemmiklooma peeve)
Atribuudid ja sildid peavad olema kõik väikesed. Ainsaks erandiks on see, kui atribuutide väärtused on mõeldud inimtoiduks, millisel juhul tuleb need kirjutada loomulikult.
Kõigil atribuutidel peab olema väärtus ja need tuleb esitada (kirjutamine) ei ole õige)
Süvendamine tuleb saavutada vahekaartide abil ja järgida loogilist struktuuri.

CSS

CSS on veel üks lõdvalt kirjutatud keel, nii et siin on ka palju tööd. Sellegipoolest lähevad standardid kodeerijate jaoks üsna lihtsaks.

Valijad

Valijad peaksid olema nii kvalifitseeritud kui vajalikud, inimlikult loetavad, kõik väiketähti kriipsudega eraldatud sõnadega ja atribuutide valijad peaksid kasutama tsiteeritud jutumärke. Siin on lühike näide:

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

Kinnisvara tellimus

Standardid tunnustavad vajadust mõne isikliku ruumi järele, kuna need ei näe ette spetsiaalset CSS-reeglite järjekorda. Mida nad teha öelda, et sa peaksid järgima semantilist struktuuri kõlab loogiliselt. Grupeerige omadused oma suhete järgi või rühmitage need tähestikulises järjekorras, lihtsalt ära kirjuta neid juhuslikult.

Juhuslikkuse suurim põhjus on “Oh ma pean lisama varu” ja seejärel jätkake selle lisamist põhjale. Võtke täiendavad 0,3 sekundit ja lisage reegel loogilisse kohta.

Ekraan
Positsioneerimine
Kasti mudel
Värvid ja tüpograafia
Muu

.profiil-modaal kuva: plokk; positsioon: absoluutne; vasakule: 100px; top: 90px; taust: # ff9900; värv: #fff;

Väärtuse vormindamine

See on üks koht, kus ma eriti vihkan vasturääkivusi. Kui te ei järgi juhiseid, on see siiski parem kui mõnikord enne väärtust näha ruumi; mõnikord kasutades stenogrammi, mõnikord mitte; mõnikord kasutatakse 0 väärtusega üksusi, mõnikord mitte jne.

Väärtuse vormindamine on üsna keeruline, kuid see on loomulikult mõne praktikaga. Vaadake koodide vormindamise täpset juhendit.

Javascript

Minu kogemus on Javascript kõige tõenäolisem, et minna üle kogu koha. Kuigi paljud arendajad teavad märkimisväärse hulga Javascripti, õpiti neid järk-järgult HTML, CSS ja PHP järel. Kui te alustate uut keelt, siis teete palju rohkem vigu ja kui need vead ei põhjusta surmavaid vigu, võivad nad teie sisse tungida.

Paljudel juhtudel viitavad standardid rea piirile või olekule “kui liin ei ole liiga pikk”. See viitab jQuery Style Guide'ile, mis paneb a 100-kohaline piirang liinidel. WordPressi juhend põhineb jQuery juhendil, nii et see on hea mõte ka lugeda.

Semikoolid

See on lihtsaim reegel, kuid see on sageli tähelepanuta jäetud. Mitte kunagi ei jäta semikoolonit lihtsalt sellepärast, et teie kood töötab ilma selleta. See on lihtsalt lohakas.

Taandumine

Tabeldusmärgid peavad alati olema sisestatud. Sul peaks olema ka sulgemise sisu, isegi kui terve faili sisu on ühes. Ma ei ole kindel, miks, kuid enne, kui ma lugesin standardeid, ei andnud mulle kinnistamata ülemise taseme sulgemist.

Lõhkumine

Pikkade stringide murdmisel katkestage alati operaatori järel rida, ärge jätke muutujat riputama. See teeb esmapilgul selgeks, et liin on katki ja te pole lihtsalt semikoolonit unustanud.

Samuti, kui tingimus on pikk, lõhkuge see mitmeks reaks ja lisage selle juurde veel üks kaart. See näeb minu silmadele väga imelik, kuid eraldatus, mida see lisab seisundi ja keha vahel, on väga nähtav.

kui (esimene tingimus) ja & secondCondition () &&clearCondition ()) var html = 'See rida koosneb sõnadest „+ n +”, seega tuleb see jaotada „+” operaatori järgi;

jQuery Iteratsioon

Vastavalt standarditele jQuery iteratsioon (jQuery.each ()) tuleks kasutada ainult jQuery objektidel. Sa peaksid kasutama põhilisi jaoks, jaoks / sisse, samal ajal silmusid Javascriptis, et itereerida üle teiste kogude.

Järeldus

Seal on palju märgata ja jälgida ning pole mingit võimalust, kuidas keegi saaks seda kõike ühel korral rakendada. Te peaksite oma koodi standarditele võimalikult lähedale võtma ja töötama nende täpselt järgides.

Minu arvates järjepidevus on kõige olulisem reegel. Parem on järjekindlalt midagi valesti teha, kui pooleldi vahetada. See kehtib eriti vormindamise tavade kohta, kuna need ei mõjuta teie koodi funktsionaalsust ja - enamasti - saab hiljem hõlpsasti partiide vahetamiseks.

Kas vihkate kodeerimisstandardite elementi, kas sa arvad, et midagi tuleks lisada? Anna meile teada oma kommentaarides!