Kodningsstandarder for WordPress [Guide]

Årsagen til, at vi overhovedet har kodningsstandarder (ikke kun for WordPress) er at skabe et velkendt miljø for programmører arbejder på et projekt. WordPress omfatter i særdeleshed en bred vifte af produkter. Fra selve kernen til temaer og plugins er der meget at se på - og meget at blande sig om.

Hvis alle formaterer deres kode på samme måde, bruger kommentarer, samme dokumentform og så videre bliver det så meget lettere at arbejde sammen, og læringskurven for at deltage i et nyt projekt vil ikke være så stejlt.

Behovet for samhørighed i WordPress forstørres af den stat, hvor codebase er. WordPress følger ikke en streng objektorienteret tilgang og bruger ikke et MVC-mønster. Projekter, der følger en OOP og MVC retningslinjer uden undtagelse (som Laravel) har konsistens og bedste praksis “bagt i” på grund af deres struktur.

WordPress er desværre moden til spaghetti kodning, aka gør hvad du vil. Bedste praksis er vanskeligt at håndhæve simpelthen fordi produkter, der anvender dårlig kode, kan fungere lige så godt (på overfladen).

Ved at følge WordPress Coding Standards kan du lære lidt om WordPress kodningsethos, skabe flere WordPress-kompatible produkter. vis det samfund, du er interesseret i, og du snyder højkvalitets kode.

Mere om Hongkiat.com:

10 værste mareridt for webudviklere
5 grunde til, at CSS kunne være det sværeste sprog for alle
30 Fælles Reaktioner Programmører har, når ting går galt

Nogle bemærkninger om standarderne

Standarden definerer ikke rigtigt og forkert. Du kan være uenig med en regel, for eksempel bør du altid bruge braces, selvom de ikke er nødvendige. Formålet med WordPress-kodningsstandarderne er ikke at afgøre, om du har ret eller forkert, det er at bestemme, hvordan det skal gøres i WordPress.

Standarderne er ikke op til debat. Brug af standarderne er ikke stedet at tage imod en indrykningsstil, du ikke kan lide. Hvis noget er i kodningsstandarderne, så gør det på den måde. WordPress-udviklere vil elske dig for det! Når det er sagt, hvis du ikke er enig i noget deri, hæve din stemme og lad folk vide det. Det er altid muligt at gøre tingene bedre, men du bør kun ændre din kodestil, hvis standarderne tillader det.

Konsistens over anal retentivitet. Hvis du er i de sidste 10% af dit projekt, og du lige har opdaget, at du har brugt den forkerte navngivningskonvention for klasser, skal du ikke skifte midtvejs. Efter min personlige mening vil jeg hellere læse noget konsekvent forkert end noget, der undertiden er korrekt og undertiden ikke. Du kan altid skrive et script for at ændre tingene på én gang, eller læse din kode i slutningen.

Følgende standarder er vanskelige! Placering af en brace på samme linje som funktionen i stedet en linje nedenfor er temmelig let, selvom du er vant til at ramme ind før. Men når du skal tænke på 100 små regler, bliver hele processen en smule fejlagtig. På trods af min hårde holdning til følgende standarder er jeg så skyldig som enhver anden på at lave fejl. I slutningen af dagen er ukorrekt indrykning ikke en uigenkaldelig synd. Prøv dit bedste for at følge alle reglerne, du lærer alt i tide.

WordPress-kodningsstandarder

For øjeblikket har WordPress fire guider, et til hvert større sprog, der anvendes: PHP, HTML, Javascript og CSS. De udgør en del af en større krop af viden, Core Contributor Handbook. At gå igennem alt ville tage et stykke tid, så jeg har fremhævet nogle uddrag fra de fire sprog, som jeg ofte ser, at folk bliver forkerte.

PHP

PHP er hovedsproget i WordPress og er et ret løst skrevet sprog, som gør det moden til regulering.

Brace Styles

Startbøjler skal altid placeres i slutningen af linjerne. Beslægtede udsagn skal placeres på samme linje som forrige lukkebøjle. Dette er bedst demonstreret med et kodeeksempel:

hvis (betingelse) // gør noget elseif (betingelse) // gør noget andet // gør noget

Generøs plads brug

Jeg er ikke fan af squashed up kode (jeg har dårligt syn), så dette er en, jeg gerne vil håndhæve. Sæt mellemrum efter kommaer, og på begge sider af logisk, sammenligning, snor og opgave operatører, efter hvis, elseif, til, for hver og kontakt udsagn og så videre.

Det er lettere at sige, hvor mellemrum ikke skal tilføjes! De eneste gange, du ikke bør tilføje mellemrum, er, hvornår typecasting eller referencerammer.

En ret forvirrende undtagelse til undtagelsen er arrays hvor matrixnøgle er en variabel, Brug i dette tilfælde et mellemrum. Dette eksempel skal gøre det klart:

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

Navngivningskonventioner

Denne kan være svært at vænne sig til, især hvis du kommer fra forskellige miljøer. I en nøddeskal:

Variable navne burde være alle små bogstaver, Ord adskilt med understreger
Klassenavne bør bruge kapitaliserede ord adskilt af understreger. Akronymer bør være alt store bogstaver
Konstanter burde være alle store bogstaver, spearated af understregninger
Filnavne burde være alle små bogstaver, adskilt med bindestreger

Yoda betingelser

Skriveforholdene omvendt, end du er vant til, vil forhindre parsing fejl. Det ser lidt underligt ud, men det er bedre kode.

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

HTML

HTML har ikke så mange regler, der er forbundet med det, jeg kunne komme helt op for at gøre tingene mere modulære. Der er kun fem regler, du skal vide, når du skriver HTML:

Din kode skal validere mod W3C-validatoren.
Selvlukkende HTML-tags skal have nøjagtigt et mellemrum før fremadrettet skråstreg (dette er et jeg personligt hader, men det er en W3C-specifikation, ikke kun et WordPress-kæledyr)
Attributter og tags skal være små bogstaver. Den eneste undtagelse er, når attributværdier er beregnet til konsum, i hvilket tilfælde de skal skrives naturligt.
Alle attributter skal have en værdi og skal citeres (skrivning er ikke korrekt)
Indrykning skal opnås ved hjælp af faner og skal følge logisk struktur.

CSS

CSS er et andet løst skrevet sprog, så der er masser af arbejde, der skal gøres her også. Alligevel går standarderne ret let på kodere.

vælgere

Selektorer skal være så kvalificerede som nødvendige, være menneskeligt læsbare, være små bogstaver med ord adskilt med bindestreger, og attributter skal bruge dobbelt citater. Her er et kort eksempel:

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

Ejendomsordre

Standarderne anerkender behovet for noget personligt rum her, da de ikke foreskriver en bestemt ordre for CSS-regler. Det de gøre sig er at du bør følge en semantisk struktur som giver mening. Grupper egenskaber ved deres forhold eller gruppér dem alfabetisk, Bare skriv dem ikke tilfældigt ud.

Den største årsag til tilfældighed er “Åh, jeg skal også tilføje en margen” og derefter fortsætter med at tilføje den til bunden. Tag de ekstra .3 sekunder og tilføj reglen på det logiske sted.

Skærm
Positionering
Box model
Farver og typografi
Andet

.profilmodal display: block; position: absolut; venstre: 100px; top: 90px; baggrund: # ff9900; farve: #fff;

Værdiformatering

Dette er et sted, hvor jeg især hader at se uoverensstemmelser. Hvis du ikke følger retningslinjerne, er det stadig bedre end nogle gange at se et mellemrum før værdien; nogle gange bruger stenografi, nogle gange ikke; nogle gange bruger enheder på 0 værdier, nogle gange ikke osv.

Værdiformatering er ret kompleks, men det kommer naturligt med en vis praksis. Tag et kig på den nøjagtige vejledning i Codex til formatering af dine værdier.

Javascript

I min erfaring er Javascript mest tilbøjelig til at gå overalt. Mens mange udviklere ved en betydelig mængde Javascript, blev de lært efterhånden som en eftertanke til HTML, CSS og PHP. Når du lige er begyndt med et nyt sprog, laver du mange flere fejl, og hvis disse fejl ikke forårsager fatale fejl, kan de blive forstyrret i dig.

I mange tilfælde refererer standarderne til en grænseværdi eller en tilstand “hvis en linje ikke er for lang”. Dette refererer til jQuery Style Guide, der pålægger a 100 tegn grænser på linjer. WordPress-vejledningen er baseret på jQuery-vejledningen, så det er en god ide at give det en læse også.

semikoloner

Dette er en enkleste regel, men er en, der ofte overses. Aldrig nogensinde udelade et semikolon, bare fordi din kode vil fungere uden det. Det er bare sjusket.

indrykning

Faner skal altid bruges til indrykning. Du bør også indrykke indholdet af en lukning, selvom indholdet af en hel fil er indeholdt i en. Jeg er ikke sikker på hvorfor, men unindented top-level lukning bugged mig selv før jeg læser standarderne.

Brydende linjer

Når du bryder lange strenger, skal du altid bryde linjen efter en operatør, lad ikke en variabel hænge om. Dette gør det klart ved første øjekast at linjen er brudt, og du har ikke bare glemt et semikolon.

Hvis en betingelse er lang, skal du også bryde den i flere linjer og tilføje en ekstra fane før den. Dette ser meget underligt ud for mine øjne, men adskillelsen det tilføjer mellem tilstanden og kroppen er meget synlig.

hvis (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Denne linje består af' + n + 'ord, så den skal opdeles efter' + 'en operatør';

jQuery Iteration

I henhold til standarderne jQuery iteration (JQuery.each ()) bør kun bruges på jQuery-objekter. Du skal bruge grundlæggende til, til / i, mens loops i Javascript for iterating over andre samlinger.

Konklusion

Der er meget at notere og holde styr på, og der er ingen måde, hvorpå man kan anvende alt dette på én gang. Du bør tage din kode så tæt som muligt på standarderne og arbejde på at følge dem nøjagtigt.

Efter min mening konsistens er den vigtigste regel. Det er bedre at konsekvent gøre noget forkert end at skifte halvvejs. Dette gælder især formateringspraksis, da disse ikke påvirker kodenes funktionalitet og - for det meste - kan nemt ændres batch senere.

Har du et element i kodningsstandarderne, tror du noget skal tilføjes? Lad os vide i kommentarerne!