Koding Standarder For WordPress [Guide]

Årsaken til at vi har kodingsstandarder i det hele tatt (ikke bare for WordPress), er å skape et kjent miljø for programmerere som arbeider med et prosjekt. WordPress omfatter spesielt et bredt utvalg av produkter. Fra selve kjerne 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 sammenhold 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 "baket 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 alltid bruke braces, selv om de ikke er nødvendig. Formålet med WordPress-kodingsstandardene er ikke å bestemme 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 navnekonvensjon 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 nedenfor, er ganske enkelt, 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 vanskelige holdning til følgende standarder er jeg så skyldig som noen andre på å gjøre feil. På slutten av dagen er feil innrykning 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, en for hvert stort 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 folk få 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 skal 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, streng og oppdrag operatører, etter om, elseif, for, foreach og bytte 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 du skriver inn eller refererer til arrays .

Et ganske forvirrende unntak fra unntaket er arrays hvor array-nøkkelen er en variabel, i dette tilfellet, bruk 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

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

• Variable navn skal være helt små bokstaver, ord skilt med understreker
• Klassenavn skal bruke aktiverte ord adskilt av understreker. Akronymer skal være alle store versjoner
• Konstanter bør være alle store, spearated av understreker
• Filnavnene skal være små bokstaver, skilt 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 ett mellomrom 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 også 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ære små bokstaver med ord skilt med bindestreker, og attributt selektorer bør bruke dobbelt anførselstegn. Her er et kort eksempel:

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

Eiendomsordre

Standarden anerkjenner behovet for personlig plass her, da de ikke foreskriver en bestemt ordre for CSS-regler. Det de sier er 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 fortsette å legge den til bunnen. Ta ekstra 0, 3 sekunder og legg til regelen på det logiske stedet.

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

 .profile-modal {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 praksis . 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 bare begynner med et nytt språk, gjør du mange flere feil, og hvis de feilene ikke fører til dødelige feil, kan de bli innblandet i deg.

I mange tilfeller refererer standardene til en linjegrense eller tilstand "hvis en linje ikke er for lang". Dette refererer til jQuery Style Guide som pålegger en grense på 100 tegn på linjer . WordPress-guiden er basert på jQuery-veiledningen, så det er en god ide å gi det en les 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 henges 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. Dette ser veldig rart ut mot øynene mine, men adskillelsen 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 skal jQuery iterasjon (jQuery.each()) bare brukes på jQuery-objekter. Du bør bruke grunnleggende for, for / i, mens 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 er konsistens 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 med batch-endring senere .

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

Dropbox's Scooter Framework gjør Sass-utvikling enda enklere

Vi vet alle om CSS-rammer og kraften de tilbyr utviklere. Men, hva med SCSS-rammer som knytter seg til Sass-arbeidsflyten ?Det er ikke mange av disse rammene rundt, men Scooter er et fint unntak. Den opprettholdes av folkene på Dropbox, og det fungerer akkurat som en frontend UI-rammeverk, men med en advarsel, det er alt bygget på SCSS .

(Tekniske og design tips)

30 Tree Tunnels som vil ta pusten fra deg

Trondunneler er en av naturens nysgjerrige og vakre fenomen . Per definisjon er en tre tunnel beskrevet som en vei eller gate som har rader med trær vokst på begge sider. Trærne danner på en måte en baldakin som gir effekten av en tunnel.Noen tre tunneler er naturlige på grunn av arten av treet grener mens andre er menneskeskapte som de er vokst på den måten ved hjelp av hagearbeid teknikker. Uanset

(Tekniske og design tips)