Põhilised kodeerimisstandardid PSR-1 kaudu

Eile rääkisin lühidalt PSR-ide kasutamise põhjendusest võrreldes WordPressi kodeerimisstandarditega ning millal ja miks mõlema puhul. Kuid see ei tähenda, et see poleks segadust tekitavate punktideta, eriti kui te nendega alles alustate, eks?

Selle all pean silmas järgmist: Oletagem, et olete aastaid töötanud WordPressi kodeerimisstandarditega (sest ma suudan nendega samastada) ja nüüd tuleb järgida täiesti uusi reegleid ja juhiseid. Kuid see pole lihtsalt tühiku muutmine ja failide ümbernimetamine.

Järgida tuleb ka teisi punkte, millest igaüks on sõna otseses mõttes (PSR-1, PSR-2 jne) välja toodud arvuna, kuidas miski peaks töötama.

Kui rääkida PSR-1-s kirjeldatud põhilistest kodeerimisstandarditest, siis millised on probleemsed valdkonnad, millega võime WordPressi arendajatena kokku puutuda?

Põhilised kodeerimisstandardid (ja kõrvalmõjud)

Mul ei ole plaanis kõiki dokumente läbi vaadata ja uuesti läbi lugeda seda, mida me saame lihtsalt neid lugedes õppida, kuid arvan, et on midagi öelda, kui võtaksime midagi, mida paljud meist teevad või kogevad, ja vaatame, kuidas see võib muutuda. WordPressi kontekstis.

Võtke näiteks Basic Coding Standardi (või PSR-1 ) kõrvalmõjud :

Fail PEAKS deklareerima uusi sümboleid (klassid, funktsioonid, konstandid jne) ega põhjusta muid kõrvalmõjusid või PEAKS täitma kõrvalmõjudega loogikat, kuid EI TOHI teha mõlemat.

Väljend "kõrvalmõjud" tähendab loogika täitmist, mis ei ole otseselt seotud klasside, funktsioonide, konstantide jne deklareerimisega, pelgalt faili kaasamisest.

Isiklikult leian, et teine ​​fraas on võti, et mõista ja vältida kõrvalmõjusid meie koodis nii palju kui võimalik. See tähendab, et kõik, mida meie klassid teevad, peaks olema iseseisev või olema sidus millegagi, mis võib olla mingil viisil süstitud.

Sellest hoolimata ei tohiks kõrvalmõju tekitava koodi leidmine ja selle puhastamine olla liiga raske. Tegelikult toon näitena ennast.

Vaadake seda konkreetset koodilõiku :

See kood on otse jaotisest Toggle Admin Notices. Tõsi, see on lihtne ja hoidlas kuvatakse märge selle muutmise kohta. See näitab siiski asja mõtet, eks?

Mis on lahendus? See toimub automaatse laadimise vormis (mida käsitleb ka PSR-4 ). Mis siis, kui ma peaksin selle taastama, nii et see järgiks PSR-1 korralikult? Siis võib üks viis selle ümberkujundamiseks välja näha järgmine :

Kas see on suurepärane näide? Ilmselt mitte. Kuid see on midagi enamat kui lihtsalt failide kaasamine. Nende failide kaasamine toob kaasa mitmesugused kõrvalmõjud.

See tähendab, et ainult see üks fail vastutab palju enama kui ainult nende nelja koodirea eest. Mõelge sellele, et see hõlmab kõike, mida teised failid rakendavad. Sel hetkel muutub see keerulisemaks.

Nii et võtke see idee ja viige see palju suuremasse süsteemi ja näete, kuidas ja miks see probleemne oleks.

Muidugi on ka alternatiivseid viise. Ja see on vaid üks näide. Ennast halvustav ka. Asi ei ole niivõrd selles, et näidata selleks lõplikku viisi, vaid hakata külvama mõtteid selle kohta, kuidas me klasse kavandame, planeerime, ehitame ja kaasame.

Aga vaated?

Mis puutub pistikprogrammide kirjutamisse, siis käsitlen seda, mida kasutajad näevad, vaadetena. Kuid tundub, et siin on konks: failide lisamist peetakse halvaks tavaks, kuna see toob kaasa kõrvalmõjusid.

Seega ei taha me oma tundides loogikat väljastada, vaid tahame ka esitluse äriloogikast eraldada.

Mida me tegema peame?

Keerd on see, et me kasutame selleks objektorienteeritud programmeerimist. Kujundame klassi, mis genereerib PHP malli abil HTML-i.

Keegi teine ​​on seda põhjalikult käsitlenud ja soovitan tungivalt seda konkreetset postitust lugeda, et võtta arvesse kõrvalmõjude ideed, neid vältida ja kasutada võimalikult palju kindlaid tavasid.

…Ja varad ja seotud failid?

Ma tean: mõte kõrvalmõjudest eemalduda (rääkimata nende tuvastamisest) võib alguses olla imelik, eriti kui mõelda teatud asjadele, mida oleme nii kaua teinud.

Ja see võib tekitada selliseid küsimusi: kas JavaScripti- või CSS-failide kaasamine on vale? See on ilmselt mõne teise postituse teema. Pidage siiski meeles, et sellega on otseselt seotud API põhifunktsioonid ja need võivad kuuluda selle eest rangelt vastutavasse klassi.

Kui klassi eesmärk on teha täpselt seda ja ainult seda ning ta kasutab selleks API funktsioone, siis ma ütleksin, et see on tõenäoliselt okei.

Kuid ma kaldun sellest praegu kõrvale (ja võib-olla on see kommentaaride või jällegi mõne muu postituse teema).

Selle asemel hoidke oma tunnid lahjad ja sihikindlad. Nad peaksid toimima nagu PSR-1 olekud ja vältima selliseid asju nagu "[deklareerida] uusi klasse, funktsioone, konstante jne". ja "[käivitab] loogikat koos kõrvalmõjudega."