WordPress-kodingsstandardene Inndeling, plassbruk og etterspørsel

Hele formålet med denne serien for å hjelpe til med å avsløre WordPress Coding Standards, hvorfor de betyr noe, og hvordan du skriver kvalitet WordPress-kode. For å gjøre dette, tar vi en grundig titt på hver del av WordPress Coding Standards.

Så langt har vi dekket:

  • Oppgi konvensjoner og funksjonsargumenter
  • Enkeltkurser og dobbeltkurser

I dag skal vi dekke betydningen av hvitt rom. Spesielt skal vi dekke innrykk, plassbruk og etterfølgende mellomrom. Så enkelt som det høres ut, er dette flere av de mest ignorert eller misbrukte aspekter av kodingsstandardene.


Et ord om hvite rom

Før vi ser på hva som skjer med de ulike kodingsstandardene, er det viktig å forstå hvorfor hvit plass er viktig, ikke bare i WordPress, men i programmeringsspråk generelt.

Enkelt sagt, det er fordi det forbedrer lesbarheten.

Dette er grunnen til at noen programmeringsspråk er mellomrom eller flipp avgrenset. Dette er grunnen til at noen programmeringsspråk ber om at du plasserer bestemte deler av koden, for eksempel funksjonsparametere, arrayindekser og mer.

Når det gjelder WordPress, er konvensjonene på plass, ikke bare for lesbarhet, men også for å gi en konsekvent lese- og utviklingserfaring for alle som jobber med WordPress-temaer, plugins, applikasjoner eller selve kjerneapplikasjonen.

Huske: Formålet med kodingsstandarder er å gjøre det slik at kildekoden ser ut som om den er skrevet av en enkelt utvikler, da det setter et forventningsnivå for å bidra til utviklere.


innrykk

Når det gjelder innrykk, er det ikke noe spesielt nytt, revolusjonerende eller annerledes som det gjelder WordPress. Generelt sett vil du sette inn hver gang du starter en ny blokk.

Dette betyr at:

  • Dine funksjoner vil være innrykket i klassen
  • Dine betingelser og bytte / tilfeller og andre blokker vil bli innrykket i deres funksjoner
  • Dine sløyfer vil bli innrykket i deres funksjoner, i deres conditionals, og så videre

Hvis du er vant til å skrive kode i C-stil språk, så er det ikke noe spesielt nytt her, riktig?

Et eksempel på hvordan dette kan se ut er akkurat dette:

 funksjon foo ($ argumenter) hvis (0 < count( $arguments )  foreach ( $arguments as $arg => $ verdi) echo $ value; 

I følge kodingsstandarder:

Din innrykk skal alltid gjenspeile logisk struktur. Bruk ekte faner og ikke mellomrom, da dette gir mest fleksibilitet over klientene.

Nøkkelfunksjonene er at begynnelsen på linjene skal begynne med faner, og at koden skal gjenspeile en logisk struktur. Ikke overkompliser eller forsøk å oversimplisere ting.

Det er en annen nyanse til hvitt mellomrom i WordPress-kodningsstandardene: Flikene skal brukes i begynnelsen av linjen, men mellomrom skal brukes overalt. For det meste er dette en enkel regel å følge; Men i WordPress, vil du ofte lage skaper for å passere som argumenter.

Ideelt sett vil vi ha hver indeks i arrayet slik at lesbarheten er så høy som mulig, men vi har ofte en tendens til å bruke faner for å gjøre det enklere å ordne dem, men dette er faktisk et brudd på kodningsstandardene.

 $ args = array ('ID' => 1, 'post_title' => 'Tittelen', 'post_content' => 'Innholdet');

Som sådan, sørg for at du bare bruk faner i begynnelsen av hver linje.


Rombruk

Som det gjelder WordPress, har jeg funnet ut at mellomrom har blitt brukt mye mer liberalt enn i andre språk. Jeg sier ikke dette bare som en observasjon, da det var en personlig tilpasning jeg trengte å gjøre i å komme både fra .NET og Ruby.

Når det er sagt, som med de fleste andre retningslinjer i Codex, er det ingenting som er spesielt komplisert; Det er imidlertid noen viktige forskjeller som må huskes når du skriver kode.

Rom bør plasseres på følgende steder:

  • Etter kommaer
  • På begge sider av logiske operatører (det vil si, ||, &&, og !)
  • På begge sider av sammenligning operatører (det er, <, >, ==, ===, etc.)
  • På begge sider av oppdragsoperatører (nemlig =)
  • På begge sider av åpningen og lukke parentesen av funksjoner, conditionals, sløyfer og så videre.
  • Når en variabel blir sendt som en indeks for en matrise, men ikke når en bokstavelig verdi (for eksempel en streng eller et heltall)

De fleste av disse er relativt rett frem, men i min erfaring har jeg funnet ut at arrayreglene har en tendens til å forårsake mest forvirring blant utviklere, så her er et raskt notat av hva som anses riktig og hva som ikke er:

 // Korrekt avstand ... $ arr [$ x] = 'foo'; $ arr [0] = 'bar'; // Feil avstand ... $ arr [$ x] = 'bar'; $ arr [0] = 'bar';

Som du kan se, er det ikke noe veldig komplisert, men det er en relativt enkel konvensjon å gå glipp av.


Trailing Spaces

Denne regelen er sannsynligvis den enkleste standarden å huske på dem alle. Enkelt sagt, det skal ikke være noen etterfølgende mellomrom på slutten av en hvilken som helst kodeks.

Avhengig av IDE, kan du ha dette filteret innebygd; andre ganger kan det hende du må installere et plugin som vil utføre denne handlingen for deg når du lagrer filen. Men uansett, det er en relativt enkel funksjon å integrere i hva IDE du bruker.

I tillegg er de fleste redaktører - uansett om det er en glorifisert tekstredigerer eller en full på IDE - du bør ha muligheten til å aktivere visning av faner og mellomrom.

Vise faner og hvite plass i Coda 2

Igjen, dette er en av de enkleste konvensjonene å følge, og det er sannsynlig at din IDE eller redigeringsvalg har denne funksjonen eller et plugin tilgjengelig som gjør at du kan gjøre dette automatisk.

Hvis ikke, bør du kunne aktivere evnen til å se faner, mellomrom, vognretur, og så videre slik at du enkelt kan identifisere hvor de bakre mellomrom er.


Konklusjon

Det er åpenbart at hvit plass plasserer en viktig rolle i å skrive WordPress-basert kode. I denne artikkelen har vi undersøkt innrykk, faner, mellomrom, etterfølgende mellomrom, og hvorfor og hvordan å innlemme dem i våre prosjekter.

I den neste artikkelen skal vi fortsette å snakke om subtilitetene i WordPress Coding Standards ved å se på brace-stil, vanlige uttrykk og nyanser av bruk av PHP-koder gjennom vår WordPress-kode.