Kodningsstandarder för WordPress [Guide]
Anledningen till att vi har kodningsstandarder alls (inte bara för WordPress) är att skapa en välbekant miljö för programmerare arbetar med ett projekt. WordPress omfattar i synnerhet ett brett utbud av produkter. Från själva kärnan till teman och plugins, det finns mycket att titta på - och mycket att bli blandad om.
Om alla formaterar sin kod på samma sätt, använder kommentarer, samma dokumentform och så vidare blir samarbetet så mycket enklare och inlärningskurvan för att ansluta sig till ett nytt projekt kommer inte att vara lika brant.
Behovet av sammanhållning i WordPress förstoras av det land där kodbasen är. WordPress följer inte ett strikt objektorienterat tillvägagångssätt och använder inte ett MVC-mönster. Projekt som följer en OOP och MVC riktlinjer utan undantag (som Laravel) har konsistens och bästa praxis “bakad i” på grund av deras struktur.
WordPress är tyvärr moget för spagetti kodning, aka gör vad du vill. Bästa praxis är svåra att genomdriva helt enkelt eftersom produkter som använder dålig kod kan fungera lika bra (på ytan).
Genom att följa WordPress-kodningsstandarderna kan du lära dig lite om WordPress kodande etos, skapa fler WordPress-kompatibla produkter. visa samhället som du bryr dig om och du slår högkvalitativ kod.
Mer på Hongkiat.com:
- 10 värsta mardrömmar för webbutvecklare
- 5 skäl till att CSS kan vara det svåraste språket för alla
- 30 Vanliga reaktioner Programmerare har när saker går fel
Några anmärkningar om standarderna
Standarden definierar inte rätt och fel. Du kan inte vara oense med en regel, till exempel bör hängslen alltid användas, även om de inte behövs. Syftet med WordPress-kodningsstandarden är inte att bestämma om du har rätt eller fel, det är att bestämma hur det ska göras i WordPress.
Standarderna är inte upp till debatt. Användningen av normerna är inte platsen för att ta ställning mot en indragningsstil du inte tycker om. Om något är i kodningsstandarden gör du det så. WordPress utvecklare kommer att älska dig för det! Med det sagt, om du inte håller med något där inne, höja din röst och låt folk veta. Det är alltid möjligt att göra saker bättre, men du bör bara ändra din kodningsstil om standarderna tillåter det.
Konsistens över anal retentivitet. Om du är i de senaste 10% av ditt projekt och du just har upptäckt att du har använt den felaktiga namngivningskonventionen för klasser, välj inte mellanväg. Enligt min personliga mening vill jag hellre läsa något konsekvent felaktigt än något som ibland är korrekt och ibland inte. Du kan alltid skriva ett skript för att ändra saker på en gång, eller läs igenom din kod i slutet.
Följande standarder är svåra! Att placera en klämma på samma linje som funktionen istället en linje nedan är ganska lätt, även om du vant är att slå in innan. Men när du behöver tänka på 100 små regler blir hela processen lite felaktig. Trots min tuffa inställning på följande standarder är jag så skyldig som någon annan att göra misstag. Vid slutet av dagen är felaktig inryckning inte en oåterkallelig synd. Försök ditt bästa att följa alla regler, du lär dig allt i tid.
WordPress kodning standarder
Just nu har WordPress fyra guider, en för varje större språk som används: PHP, HTML, Javascript och CSS. De utgör en del av en större kännedom, Core Contributor Handbook. Att gå igenom allt skulle ta ett tag så jag har markerat några utdrag från de fyra språken som jag ofta ser att människor blir felaktiga.
PHP
PHP är huvudspråket i WordPress och är ett ganska löst typat språk vilket gör det modet för reglering.
Brace Styles
Startstöd bör alltid placeras i slutet av raderna. Relaterade uttalanden ska placeras på samma rad som föregående stängningsstöd. Detta visas bäst med ett kodexempel:
om (villkor) // gör någonting elseif (villkor) // gör någonting annat // gör någonting
Generös rymdanvändning
Jag är inte ett fan av squashed up-kod (jag har dålig syn) så det här är en som jag särskilt gillar att genomdriva. Sätt utrymmen efter kommatecken, och på båda sidor av logisk, jämförelse, sträng och uppdragsoperatörer, efter om, elseif, för, för varje och växla uttalanden och så vidare.
Det är lättare att säga varav mellanslag inte ska läggas till! De enda tiderna du inte bör lägga till mellanslag är när type-casting eller referensramar.
Ett ganska förvirrande undantag till undantaget är arrays där matrisnyckel är en variabel, använd i så fall ett mellanslag. Detta exempel borde göra det klart:
funktion my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array; annat $ key_1 = (heltal) $ key_1; $ final_array [0] = 'this'; $ final_array [$ key_1] = 'är'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'example'; returnera $ final_array;
Namnkonventioner
Det här kan vara svårt att vänja sig, särskilt om du kommer från olika miljöer. I ett nötskal:
- Variable namn borde vara alla små bokstäver, Ord åtskilda med understreck
- Klassnamn borde använda kapitaliserade ord åtskilda av underskrifter. förkortningar borde vara allt versal
- Konstanter anter~~POS=HEADCOMP borde vara alla stora versioner, spearated av understreck
- Filnamn borde vara alla små bokstäver, separerade med bindestreck
Yoda-förhållanden
Skrivförhållanden tvärtom än vad du brukar förhindra att du analyserar fel. Det ser lite konstigt ut, men det är bättre kod.
om ('Daniel' === $ namn) echo 'Skriv artikel du kommer'; html
HTML har inte så många regler som är förknippade med det, jag kunde komma med ganska mycket för att göra saker mer modulära. Det finns bara fem regler du behöver veta när du skriver HTML:
- Din kod måste validera mot W3C-valideraren.
- Självslutande HTML-taggar måste ha exakt ett utrymme före framåtskuren (det här är jag personligen hat, men det är en W3C-specifikation, inte bara ett WordPress-husdjur)
- Attribut och taggar måste vara små bokstäver. Det enda undantaget är när attributvärden är avsedda för konsumtion, i vilket fall de ska skrivas naturligt.
- Alla attribut måste ha ett värde och måste citeras (skrivande
är inte korrekt) - Indryckning bör uppnås med hjälp av flikar och bör följa den logiska strukturen.
CSS
CSS är ett annat löst skrivet språk, så det finns mycket arbete att göra här också. Ändå går standarderna ganska enkelt på kodare.
väljare
Selektörer ska vara kvalificerade som nödvändiga, vara mänskliga läsbara, vara alla små bokstäver med ord åtskilda med bindestreck, och attribut väljare bör använda dubbla citat. Här är ett kortfattat exempel:
skriv in [typ = "text"], skriv in [typ = "lösenord"], .namn-fält bakgrund: # f1f1f1;
Fastighetsbeställning
Standarderna erkänner behovet av lite personligt utrymme här, eftersom de inte föreskriver en särskild ordning för CSS-regler. Vad de do säg att du borde följa en semantisk struktur som är vettigt. Grupp egenskaper genom sina relationer eller gruppera dem i alfabetisk ordning, skriv inte ut dem slumpmässigt.
Den största orsaken till slumpmässighet är “åh måste jag också lägga till en marginal” och fortsätter sedan för att lägga till det i botten. Ta extra 0,3 sekunder och lägg till regeln på den logiska platsen.
- Visa
- positionering
- Boxmodell
- Färger och typografi
- Andra
.profilmodell display: block; position: absolute; vänster: 100px; top: 90px; bakgrund: # ff9900; färg: #fff;
Värdesformatering
Det här är en plats där jag särskilt hatar att se motsättningar. Om du inte följer riktlinjerna, är det fortfarande bättre än att ibland se ett utrymme före värdet. ibland använder stenografi, ibland inte; ibland använder enheter på 0 värden, ibland inte etc.
Värdesformatering är ganska komplicerad men det kommer naturligt med viss övning. Ta en titt på den exakta guiden i Codex för att formatera dina värden.
Javascript
Enligt min erfarenhet är Javascript mest benägen att gå överallt. Medan många utvecklare känner till en betydande mängd Javascript, lärdes de sig gradvis, som en eftertanke till HTML, CSS och PHP. När du bara börjar med ett nytt språk gör du mycket fler misstag och om de misstag inte orsakar dödliga fel kan de bli inkräkta på dig.
I många fall hänvisar standarderna till en gränsgräns eller ett tillstånd “om en linje inte är för lång”. Detta hänvisar till jQuery Style Guide som lägger upp en 100 tecken gräns på linjer. WordPress-guiden är baserad på jQuery-guiden, så det är en bra idé att ge en läs också.
Semikolon
Detta är en enklaste regel men är en som ofta förbises. Aldrig, utelämna aldrig en semikolon bara för att din kod kommer att fungera utan den. Det är bara slarvigt.
indrag
Flikar ska alltid användas för indragning. Du bör också ange innehållet i en stängning även om innehållet i en hel fil finns i en. Jag är inte säker på varför men oupphörlig toppnivån stängde mig innan jag läste standarderna.
Brytlinjer
Vid brytning av långa strängar, bryta alltid linjen efter en operatör, Lämna inte en variabel som hänger på. Detta gör det uppenbart vid första anblicken att linjen är trasig och du har inte bara glömt en semikolon.
Om ett villkor är långt, bryter du det också till flera rader och lägger till en extra flik före den. Den här ser väldigt konstig ut mot mina ögon, men den separation det lägger till mellan tillståndet och kroppen är mycket synligt.
if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Den här raden består av' + n + 'ord, så den ska delas upp efter' + 'en operatör';
jQuery Iteration
Enligt standarderna jQuery iteration (JQuery.each ()) bör endast användas på jQuery-objekt. Du borde använda grundläggande för, för / i, medan loopar i Javascript för iterering över andra samlingar.
Slutsats
Det finns mycket att notera och hålla reda på och det finns inget sätt någon kan tillämpa allt detta på en gång. Du bör ta din kod så nära som möjligt till standarderna och arbeta för att följa dem exakt.
Enligt min åsikt konsistens är den viktigaste regeln. Det är bättre att konsekvent göra någonting felaktigt än att byta halvvägs. Detta gäller speciellt med formateringspraxis eftersom dessa inte påverkar funktionen i din kod och - för det mesta - kan enkelt bytas ut senare.
Hatar du ett element i kodningsstandarden, tror du att något borde läggas till? Låt oss veta i kommentarerna!
