WordPress kodēšanas standarti [Guide]

Iemesls, kāpēc mums vispār ir kodēšanas standarti (ne tikai WordPress), ir izveidot pazīstamu vidi programmētājiem darbs pie projekta. WordPress jo īpaši ietver plašu produktu klāstu. No paša koda līdz motīviem un spraudņiem ir daudz ko aplūkot - un daudz ko var sajaukt.

Ja visi formāti kodē tādā pašā veidā, izmanto komentārus, to pašu dokumentācijas stilu un tā tālāk, kopīga sadarbība kļūst tik daudz vieglāka, un mācīšanās līkne pievienoties jaunam projektam nebūs tik stāvīga.

Vajadzību pēc kohēzijas WordPress palielina stāvoklis, kurā koda bāze ir. WordPress neizmanto stingru objektorientētu pieeju un neizmanto MVC modeli. Projektiem, kas seko OOP un MVC vadlīnijām bez izņēmuma (piemēram, Laravel), ir konsekvence un labākā prakse “cepta” to struktūras dēļ.

WordPress diemžēl ir gatavs spageti kodēšanai darot visu, ko vēlaties. Labāko praksi ir grūti īstenot tikai tāpēc, ka produkti, kas izmanto sliktu kodu, var darboties tikpat labi (uz virsmas).

Sekojot WordPress kodēšanas standartiem, jūs varat uzzināt nedaudz par WordPress kodēšanas ētiku, veidot vairāk WordPress saderīgus produktus. parādīt kopienu, ar kuru jūs rūpējāt, un jūs kliedzat augstas kvalitātes kodu.

Vairāk par Hongkiat.com:

10 sliktākie murgi tīmekļa izstrādātājiem
5 iemesli, kāpēc CSS varētu būt vissmagākā valoda
30 Kopīgas reakcijas Programmētājiem ir, kad lietas notiek nepareizi

Dažas piezīmes par standartiem

Standarti nenosaka pareizo un nepareizo. Jūs varat nepiekrist noteikumam, piemēram, vienmēr jāizmanto bikšturi, pat ja tie nav vajadzīgi. WordPress kodēšanas standartu mērķis nav izlemt, vai esat pareizi vai nepareizi, tas ir izlemt, kā tas jādara programmā WordPress.

Standarti nav debašu laikā. Standartu izmantošana nav vieta, kur ņemt nostāju pret atkāpšanās stilu, kas jums nepatīk. Ja kaut kas ir kodēšanas standartos, tad dariet to šādā veidā. WordPress izstrādātāji tevi mīlēs! Tas nozīmē, ka, ja jūs nepiekrītat kaut kādam tur, palieliniet savu balsi un ļaujiet cilvēkiem uzzināt. Vienmēr ir iespējams darīt labāk, bet kodēšanas stilu vajadzētu mainīt tikai tad, ja standarti to atļauj.

Konsekvence attiecībā uz analoģiju. Ja esat pēdējos 10% no sava projekta un esat tikko atklājis, ka esat izmantojis nepareizu nosaukumu klasi, nevajag pārslēgties vidū. Manā personīgajā viedoklī es drīzāk izlasītu kaut ko nepareizi, nekā tas, kas reizēm ir pareizs un dažreiz nav. Jūs vienmēr varat rakstīt skriptu, lai vienā reizē mainītu lietas, vai arī beigās izlasiet savu kodu.

Šādi standarti ir grūti! Līmenu novietošana tajā pašā rindā kā funkcija, nevis zemāk esošā līnija, ir diezgan vienkārša, pat ja esat pieradis nokļūt iepriekš. Tomēr, ja jums ir jādomā par 100 maziem noteikumiem, viss process kļūst mazliet kļūdains. Neskatoties uz manu stingro nostāju attiecībā uz šādiem standartiem, es esmu tikpat vainīgs kā jebkurš cits par kļūdām. Dienas beigās nepareiza atkāpe nav neatsaucams grēks. Mēģiniet vislabāk ievērot visus noteikumus, jūs visu laiku uzzināsiet.

WordPress kodēšanas standarti

Šobrīd WordPress ir četras rokasgrāmatas, viena no katras galvenās valodas: PHP, HTML, Javascript un CSS. Tie veido daļu no plašākas zināšanu kopas - Core Contributor Handbook. Viss, kas iet cauri visam, aizņems kādu laiku, tāpēc es esmu izcelusi dažus fragmentus no četrām valodām, kuras es bieži redzu, ka cilvēki kļūst nepareizi.

PHP

PHP ir WordPress galvenā valoda, un tā ir diezgan brīvi ievadīta valoda, kas padara to gatavu regulēt.

Brace stili

Startējošās bikšturi vienmēr jānovieto līniju beigās. Saistītie paziņojumi jānovieto vienā rindā ar iepriekšējo aizvēršanu. To vislabāk demonstrē ar koda piemēru:

ja (nosacījums) // Vai kaut kas elseif (stāvoklis) // Vai kaut kas cits // Vai kaut kas

Plaša kosmosa izmantošana

Es neesmu ventilatora no saspiestā koda (man ir slikta redze), tāpēc es īpaši gribu to izpildīt. Pēc tam ievietojiet atstarpes komatiem, un abās pusēs loģiski, salīdzinājums, virkne un piešķiršanas operatoriem, pēc tam ja, citur, par, katram un slēdzis paziņojumi utt.

Ir vieglāk pateikt, kur nedrīkst pievienot atstarpes! Vienīgais laiks, kad nevajadzētu pievienot atstarpes, ir tad, kad tipecasting vai atsauces masīvi.

Diezgan mulsinošs izņēmums izņēmumam ir masīvi, kur masīvs ir mainīgais, šajā gadījumā izmantojiet atstarpi. Šajā piemērā būtu skaidri jānorāda:

funkcija my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  cits $ key_1 = (vesels skaitlis) $ key_1; $ final_array [0] = 'tas'; $ final_array [$ key_1] = 'ir'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'piemērs';  atgriezties $ final_array;

Nosaukuma konvencijas

Tas var būt grūti pierast, it īpaši, ja nāk no dažādām vidēm. Īsumā:

Mainīgie nosaukumi vajadzētu būt visi mazie burti, vārdi atdalīti ar pasvītrojumiem
Klases nosaukumi jāizmanto kapitalizēti vārdi atdalītas ar pasvītrojumiem. Akronīmi jābūt visiem lielie burti
Konstantes vajadzētu būt visi lielie burti, spearated ar pasvītrojumiem
Failu nosaukumi vajadzētu būt visi mazie burti, atdalīt ar domuzīmēm

Yoda nosacījumi

Rakstot nosacījumus citādi, nekā jūs esat pieradis, novērsīs kļūdas. Tas izskatās nedaudz dīvaini, bet tas ir labāks kods.

ja ('Daniel' === $ nosaukums) echo "Rakstīt rakstu, ko jūs gatavojaties";

HTML

HTML nav tik daudz noteikumu, kas saistīti ar to, es varētu nākt klajā ar diezgan daudz, lai padarītu lietas vairāk moduļu. Rakstot HTML, ir jāzina tikai pieci noteikumi:

Jūsu kodam jāapstiprina pret W3C validatoru.
Pašaizverošiem HTML tagiem jābūt tieši vienai telpai pirms priekšgala slīpsvītra (tas ir viens, ko es personīgi ienīstu, bet tā ir W3C specifikācija, ne tikai WordPress pet peeve)
Atribūtiem un tagiem jābūt visiem mazajiem burtiem. Vienīgais izņēmums ir, ja atribūtu vērtības ir paredzētas lietošanai pārtikā, un tādā gadījumā tās drukā dabiski.
Visiem atribūtiem jābūt ar vērtību un tie ir jānorāda (rakstot nav pareizs)
Atcelšana ir jāsasniedz, izmantojot cilnes, un tai ir jāievēro loģiskā struktūra.

CSS

CSS ir vēl viena brīvi rakstīta valoda, tāpēc šeit ir arī daudz darāmā. Tomēr standarti kodētājiem ir diezgan vienkārši.

Atlasītāji

Atlasītājiem jābūt tik kvalificētiem, cik nepieciešams, tie ir cilvēciski salasāmi, visi mazie burti ar vārdiem, kas atdalīti ar svītrām, un atribūtu atlasītājiem jāizmanto dubultās pēdiņas. Šeit ir īss piemērs:

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

Īpašuma pasūtījums

Standarti atzīst nepieciešamību pēc dažām personiskām telpām, jo tās neparedz īpašu CSS noteikumu kārtību. Ko viņi darīt teikt, ka jums vajadzētu sekot semantiskai struktūrai ir jēga. Grupējiet īpašības pēc to attiecībām vai grupējiet tās alfabēta secībā, vienkārši neuzrakstiet tos nejauši.

Lielākais nejaušības cēlonis ir “oh Man arī jāpievieno rezerve” un pēc tam turpiniet to pievienot apakšai. Paņemiet papildu 3 sekundes un pievienojiet likumu loģiskā vietā.

Displejs
Pozicionēšana
Kastes modelis
Krāsas un tipogrāfija
Citi

.profila modāls displejs: bloks; pozīcija: absolūta; pa kreisi: 100px; tops: 90px; fons: # ff9900; krāsa: #fff;

Vērtību formatēšana

Šī ir viena vieta, kur es īpaši ienīstu pretrunas. Ja jūs neievērojat vadlīnijas, tas joprojām ir labāks nekā reizēm redzēt vietu pirms vērtības; dažreiz izmantojot stenogrāfiju, dažreiz ne; dažreiz izmantojot vienības uz 0 vērtībām, dažreiz ne utt.

Vērtību formatēšana ir diezgan sarežģīta, bet tas dabiski nāk ar kādu praksi. Apskatiet precīzu rokasgrāmatu Codex, lai formatētu savas vērtības.

Javascript

Manā pieredzē Javascript ir vislielākā tendence iet pa visu vietu. Kaut arī daudzi izstrādātāji zina ievērojamu daudzumu Javascript, tas tika iemācīts pakāpeniski, kā vēlāk, domājot par HTML, CSS un PHP. Kad jūs tikko sākat darbu ar jaunu valodu, jūs kļūdīsieties daudz vairāk, un, ja šīs kļūdas nerada letālas kļūdas, tās var iesakņoties jums.

Daudzos gadījumos standarti attiecas uz līnijas robežu vai stāvokli “ja līnija nav pārāk garš”. Tas attiecas uz jQuery Style Guide, kas nosaka 100 rakstzīmju ierobežojums līnijās. WordPress rokasgrāmata ir balstīta uz jQuery rokasgrāmatu, tāpēc tā ir laba ideja, lai arī to lasītu.

Semikoli

Tas ir vienkāršākais noteikums, bet bieži vien tas tiek ignorēts. Nekad nekad neizlaidiet semikolu tikai tāpēc, ka jūsu kods darbosies bez tā. Tas ir tikai apliets.

Indikācija

Cilnēm vienmēr jāizmanto cilnes. Jums ir arī jānorāda slēgšanas saturs pat tad, ja visa faila saturs ir ietverts vienā. Es neesmu pārliecināts, kāpēc, bet nejautāts augstākā līmeņa slēgums mani izjauca vēl pirms standartu izlasīšanas.

Lūzumu līnijas

Sadalot garās virknes, vienmēr izjauciet līniju pēc operatora, neatstājiet mainīgo, kas ir paralēli. Tas padara acīmredzamu no pirmā acu uzmetiena redzamu, ka līnija ir bojāta, un jūs vienkārši neesat aizmirsis semikolu.

Arī tad, ja nosacījums ir garš, sadaliet to vairākās rindās un pirms tam pievienojiet papildu cilni. Tas man šķiet ļoti dīvaini, bet atšķirtība, ko tas papildina starp stāvokli un ķermeni, ir ļoti redzama.

ja (pirmais nosacījums () & & otrais nosacījums () &&courition ()) var html = 'Šī rinda sastāv no vārdiem “+ n +”, tāpēc tā jāsadala pēc “+” operatora;

jQuery Iterācija

Saskaņā ar standartiem jQuery iterāciju (jQuery.each ()) drīkst izmantot tikai uz jQuery objektiem. Jums vajadzētu izmantot pamata par, par / in, kamēr cilpas Javascript, lai iterētu pār citām kolekcijām.

Secinājums

Ir daudz ko atzīmēt un sekot līdzi, un nav nekāda veida, kā kāds to varētu izmantot vienā reizē. Jums vajadzētu ņemt savu kodu tik tuvu, cik iespējams, standartiem un strādāt, lai tos precīzi ievērotu.

Pēc manām domām konsekvence ir vissvarīgākais noteikums. Tas ir labāk konsekventi darīt kaut ko nepareizi, nekā pāriet uz pusi. Tas jo īpaši attiecas uz formatēšanas praksi, jo tie neietekmē jūsu koda funkcionalitāti un - lielākoties - vēlāk var viegli nomainīt.

Vai jūs ienīstat kodēšanas standartu elementu, vai jūs domājat, ka kaut kas būtu jāpievieno? Informējiet mūs komentāros!