Koding Standarder For WordPress [Guide]

Årsaken til at vi har kodingsstandarder i det hele tatt (ikke bare for WordPress) er å opprett et kjent miljø for programmerere jobber med et prosjekt. WordPress omfatter spesielt et bredt utvalg av produkter. Fra kjernen til temaer og plugins, er det mye å se på - og mye å bli blandet opp om.

Hvis alle formaterer koden på samme måte, bruker kommentarer, samme stil med dokumentasjon og så videre, blir samarbeidet så mye lettere, og læringskurven for å bli med et nytt prosjekt vil ikke være like bratt.

Behovet for sammenheng i WordPress forstørres av staten der kodebase er. WordPress følger ikke en streng objektorientert tilnærming og bruker ikke et MVC-mønster. Prosjekter som følger en OOP og MVC retningslinjer uten unntak (som Laravel) har konsistens og beste praksis “bakt inn” på grunn av deres struktur.

WordPress er dessverre moden til spaghetti-koding, aka gjør hva du vil. Beste praksis er vanskelig å håndheve rett og slett fordi produkter som bruker dårlig kode, kan fungere like bra (på overflaten).

Ved å følge WordPress Coding Standards kan du lære litt om kodingsetoden for WordPress, opprette flere WordPress-kompatible produkter. vis fellesskapet du bryr deg om, og du slår høykvalitets kode.

Mer på Hongkiat.com:

• 10 verste mareritt for webutviklere
• 5 grunner til at CSS kan være det vanskeligste språket for alle
• 30 Vanlige Reaksjoner Programmører har når ting går galt

Noen notater på standardene

Standarden definerer ikke riktig og galt. Du kan være uenig med en regel, for eksempel bør du bruke braces alltid, selv om de ikke er nødvendig. Formålet med WordPress-kodingsstandardene er ikke å avgjøre om du har rett eller galt, det er å bestemme hvordan det skal gjøres i WordPress.

Standarden er ikke opp til debatt. Bruk av standardene er ikke stedet å ta imot en innrykksstil du ikke liker. Hvis noe er i kodingsstandarden, gjør du det på den måten. WordPress utviklere vil elske deg for det! Når det er sagt, hvis du ikke er enig med noe der inne, øk din stemme og la folk få vite det. Det er alltid mulig å gjøre ting bedre, men du bør bare endre kodestilen din hvis standardene tillater det.

Konsistens over anal retentivitet. Hvis du er i de siste 10% av prosjektet ditt, og du nettopp har oppdaget at du har brukt feil navngivningskonvensjon for klasser, må du ikke bytte midtveis. I min personlige mening vil jeg heller lese noe konsekvent feil enn noe som noen ganger er riktig og noen ganger ikke. Du kan alltid skrive et skript for å endre ting på en gang, eller lese koden din på slutten.

Følgende standarder er vanskelig! Å sette en brace på samme linje som funksjonen i stedet en linje under er ganske enkel, selv om du er vant til å slå inn før. Men når du trenger å tenke på 100 små regler, blir hele prosessen litt feilaktig. Til tross for min tøffe holdning til følgende standarder er jeg så skyldig som noen andre på å gjøre feil. På slutten av dagen er feil innrykk ikke en uigenkallelig synd. Prøv ditt beste for å følge alle reglene, du lærer alt i tide.

WordPress-kodingsstandarder

For øyeblikket har WordPress fire guider, ett for hvert større språk som brukes: PHP, HTML, Javascript og CSS. De er en del av en større kunnskapsdel, Core Contributor Handbook. Å gå gjennom alt vil ta en stund, så jeg har uthevet noen utdrag fra de fire språkene som jeg ofte ser at folk blir feil.

PHP

PHP er hovedspråket i WordPress og er et ganske løst skrevet språk som gjør det moden til regulering.

Brace Styles

Startspor bør alltid plasseres på slutten av linjene. Beslektede utsagn skal plasseres på samme linje som forrige lukkebøyle. Dette er best demonstrert med et kodeksempel:

hvis (tilstand) // Gjør noe elseif (tilstand) // Gjør noe annet // Gjør noe

Generøs plassbruk

Jeg er ikke en fan av squashed up kode (jeg har dårlig syn) så dette er en jeg liker spesielt å håndheve. Sett mellomrom etter komma, og på begge sider av logisk, sammenligning, string og oppdrag operatører, etter hvis, eller hvis, til, for hver og bytte om uttalelser og så videre.

Det er lettere å si hvor mellomrom ikke skal legges til! De eneste tider du ikke bør legge til mellomrom er når typecasting eller referanse arrays.

Et ganske forvirrende unntak fra unntaket er arrays der array nøkkelen er en variabel, Bruk i så fall et mellomrom. Dette eksemplet skal gjøre dette klart:

funksjon my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  ellers $ key_1 = (heltall) $ key_1; $ final_array [0] = 'this'; $ final_array [$ key_1] = 'er'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example';  returnere $ final_array; 

Naming Conventions

Denne kan være vanskelig å bli vant til, spesielt hvis du kommer fra forskjellige miljøer. I et nøtteskall:

• Variable navn bør være alle små bokstaver, ord skilt med understreker
• Klassenavn bør bruke kapitaliserte ord skilt av understreker. akronymer bør være alt stor bokstav
• konstanter bør være alle store versjoner, spearated av understreker
• Filnavn bør være alle små bokstaver, separert med bindestreker

Yoda betingelser

Skriveforhold på den andre siden enn du pleier å forhindre parsing feil. Det ser litt rart ut, men det er bedre kode.

hvis ('Daniel' === $ navn) echo 'Skriv artikkelen du vil'; 

HTML

HTML har ikke så mange regler som er knyttet til det, jeg kunne komme opp med å gjøre ting mer modulære. Det er bare fem regler du trenger å vite når du skriver HTML:

1. Koden din må validere mot W3C-validatoren.
2. Selvlukkende HTML-koder må ha nøyaktig en plass før fremoverstreket (dette er en jeg personlig hater, men det er en W3C-spesifikasjon, ikke bare et WordPress-kjæledyr)
3. Attributter og koder må være små bokstaver. Det eneste unntaket er når attributtverdier er ment for konsum, i så fall skal de skrives naturlig.
4. Alle attributter må ha en verdi og må siteres (skriving er ikke riktig)
5. Innrykk skal oppnås ved hjelp av faner og skal følge logisk struktur.

CSS

CSS er et annet løst skrevet språk, så det er mye arbeid å gjøre her også. Likevel går standardene ganske enkelt på kodere.

velgere

Selektorer bør være så kvalifiserte som nødvendige, være menneskelige lesbare, vær alle små bokstaver med ord skilt med bindestreker, og attributt selektorer skal bruke dobbelt anførselstegn. Her er et kort eksempel:

skriv inn [type = "tekst"], skriv inn [type = "passord"], .navn-felt bakgrunn: # f1f1f1; 

Eiendomsordre

Standarden gjenkjenner behovet for personlig plass her, da de ikke foreskriver en bestemt ordre for CSS-regler. Hva de gjøre si at du bør følge en semantisk struktur som gir mening. Grupper egenskaper ved deres forhold eller grupper dem alfabetisk, bare skriv dem ikke ut tilfeldig.

Den største årsaken til tilfeldighet er “oh jeg må også legge til en margin” og deretter fortsetter å legge den til bunnen. Ta ekstra .3 sekunder og legg til regelen på det logiske stedet.

• Vise
• posisjonering
• Boksmodell
• Farger og typografi
• Annen

.profilmodell display: block; stilling: absolutt; venstre: 100px; top: 90px; bakgrunn: # ff9900; farge: #fff; 

Verdiformatering

Dette er et sted hvor jeg spesielt hater å se uoverensstemmelser. Hvis du ikke følger retningslinjene, er det fortsatt bedre enn noen ganger å se et mellomrom før verdien; Noen ganger bruker stenografi, noen ganger ikke; noen ganger bruker enheter på 0 verdier, noen ganger ikke osv.

Verdiformatering er ganske komplisert, men det kommer naturlig med litt øvelse. Ta en titt på den nøyaktige veiledningen i Codex for å formatere verdiene dine.

Javascript script~~POS=HEADCOMP

I min erfaring er Javascript mest utsatt for å gå over alt. Mens mange utviklere vet en betydelig mengde Javascript, ble det lært gradvis, som en ettertanke til HTML, CSS og PHP. Når du nettopp har startet med et nytt språk, gjør du mange flere feil, og hvis de feilene ikke forårsaker fatale feil, kan de bli innblandet i deg.

I mange tilfeller refererer standardene til en linjegrense eller en tilstand “hvis en linje ikke er for lang”. Dette refererer til jQuery Style Guide som pålegger a 100 tegn grense på linjer. WordPress-guiden er basert på jQuery-veiledningen, så det er en god ide å gi det en lesing også.

semikolon

Dette er en enkleste regel, men er en som ofte overses. Aldri, aldri utelate en semikolon bare fordi koden din vil fungere uten den. Det er bare slurvet.

innrykk

Faner skal alltid brukes til innrykning. Du bør også legge inn innholdet i en lukking selv om innholdet i en hel fil er inneholdt i en. Jeg er ikke sikker på hvorfor, men unindented top-level closure bugged meg selv før jeg leste standarder.

Bryte linjer

Når du bryter lange strenger, bryter du alltid linjen etter en operatør, ikke la en variabel henge om. Dette gjør det klart ved første øyekast at linjen er ødelagt, og du har ikke bare glemt et semikolon.

Også, hvis en tilstand er lang, bryter den inn i flere linjer og legger til en ekstra fane før den. Denne ser veldig rar på øynene mine, men separasjonen det legger til mellom tilstanden og kroppen er veldig synlig.

hvis (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Denne linjen består av' + n + 'ord, så den skal brytes ned etter' + 'en operatør'; 

jQuery Iteration

I henhold til standardene jQuery iterasjon (JQuery.each ()) bør bare brukes på jQuery-objekter. Du bør bruke grunnleggende til, for i, samtidig som looper i Javascript for iterating over andre samlinger.

Konklusjon

Det er mye å merke seg og holde styr på, og det er ingen måte noen kan søke alt dette på en gang. Du bør ta koden så nært som mulig til standardene og arbeidet med å følge dem nøyaktig.

Etter min mening konsistens er den viktigste regelen. Det er bedre å konsekvent gjøre noe feil enn å bytte halvveis. Dette gjelder spesielt for formateringspraksis, siden disse ikke påvirker funksjonaliteten til koden din og - for det meste - kan enkelt endres batch-endret senere.

Hater du et element av kodningsstandardene, tror du noe skal legges til? Gi oss beskjed i kommentarene!