Codeerstandaarden voor WordPress [Guide]

De reden dat we codeerstandaarden hebben (niet alleen voor WordPress) is om creëer een vertrouwde omgeving voor programmeurs aan een project werken. Vooral WordPress omvat een breed scala aan producten. Van de kern zelf tot thema's en plug-ins, er is veel om naar te kijken - en veel om in de war te raken.

Als iedereen zijn code op dezelfde manier opmaakt, opmerkingen gebruikt, dezelfde stijl van documentatie enzovoort, wordt samenwerken veel gemakkelijker en de leercurve van deelname aan een nieuw project zal niet zo steil zijn.

De behoefte aan samenhang in WordPress wordt vergroot door de staat waarin de codebase zich bevindt. WordPress volgt geen strikte objectgeoriënteerde benadering en maakt geen gebruik van een MVC-patroon. Projecten die zonder uitzondering een OOP- en MVC-richtlijnen volgen (zoals Laravel) hebben consistentie en beste praktijken “gebakken” vanwege hun structuur.

WordPress is helaas rijp voor spaghetti-codering, aka doen wat je wilt. Best practices zijn moeilijk te handhaven, simpelweg omdat producten met slechte code net zo goed kunnen werken (aan de oppervlakte).

Door de WordPress coderingsstandaarden te volgen, kunt u iets leren over de coderingsethos van WordPress, meer WordPress-compatibele producten maken. laat de gemeenschap zien dat het jou interesseert en je ruilt code van hoge kwaliteit.

Meer over Hongkiat.com:

• 10 slechtste nachtmerries voor webontwikkelaars
• 5 redenen waarom CSS de moeilijkste taal van allemaal zou kunnen zijn
• 30 Gemeenschappelijke reacties Programmeurs hebben wanneer het mis gaat

Enkele opmerkingen over de normen

De normen definiëren niet goed en fout. U kunt het niet eens zijn met een regel, bijvoorbeeld accolades moeten altijd worden gebruikt, ook als ze niet nodig zijn. Het doel van de WordPress-coderingsnormen is niet om te beslissen of je gelijk hebt of niet, het is om te beslissen hoe het moet worden gedaan in WordPress.

De normen staan ​​niet ter discussie. Het gebruik van de normen is niet de plaats om stelling te nemen tegen een inspringstijl die u niet bevalt. Als iets in de coderingsnormen staat, doe het dan op die manier. WordPress-ontwikkelaars zullen er dol op zijn! Dat gezegd hebbende, als je het niet eens bent met iets daarbinnen, verhef je je stem en laat het mensen weten. Het is altijd mogelijk om dingen beter te doen, maar je moet alleen je coderingsstijl wijzigen als de normen dit toestaan.

Consistentie over anale retentiviteit. Als je in de laatste 10% van je project zit en je hebt net ontdekt dat je de onjuiste naamgevingsconventie voor klassen hebt gebruikt, schakel dan niet halverwege. In mijn persoonlijke mening lees ik liever iets dat consequent incorrect is dan iets dat soms juist is en soms niet. Je kunt altijd een script schrijven om dingen in één keer te veranderen of aan het eind je code door te lezen.

Het volgen van standaarden is moeilijk! Het plaatsen van een accolade op dezelfde regel als de functie, in plaats daarvan is een regel eronder vrij eenvoudig, zelfs als je gewend bent om eerder op enter te drukken. Wanneer u echter aan 100 kleine regels moet denken, wordt het hele proces een beetje foutgevoelig. Ondanks mijn harde houding ten aanzien van het volgen van normen, ben ik net zo schuldig als iemand anders over het maken van fouten. Aan het einde van de dag is onjuiste inspringing geen onherroepelijke zonde. Probeer je best om alle regels te volgen, je leert alles op tijd.

WordPress coderingsstandaarden

Op dit moment heeft WordPress vier handleidingen, één voor elke belangrijke gebruikte taal: PHP, HTML, Javascript en CSS. Ze vormen een onderdeel van een grotere hoeveelheid kennis, het handboek van Core Contributor. Alles doorlopen zou een tijdje duren, dus ik heb een aantal fragmenten uit de vier talen naar voren gebracht, die ik regelmatig zie dat mensen het mis hebben.

PHP

PHP is de hoofdtaal van WordPress en is een vrij losse taal waardoor het rijp is voor regulering.

Brace Styles

Startbraces moeten altijd aan het einde van de regels worden geplaatst. Gerelateerde uitspraken moeten op dezelfde regel worden geplaatst als de vorige sluitingssteun. Dit wordt het best gedemonstreerd met een codevoorbeeld:

if (voorwaarde) // Do Something elseif (condition) // Do Something else // Do Something

Royaal ruimtegebruik

Ik ben geen fan van geplette code (ik heb een slecht gezichtsvermogen), dus dit is er een die ik vooral graag wil afdwingen. Zet spaties na komma's, en aan beide kanten van logisch, vergelijking, draad en toewijzingsoperators, na als, elseif, voor, foreach en schakelaar verklaringen enzovoort.

Het is gemakkelijker om te zeggen waar ruimten niet mogen worden toegevoegd! De enige keer dat u geen spaties mag toevoegen, is wanneer typecasting of verwijzingen naar arrays.

Een nogal verwarrende uitzondering op de uitzondering is arrays waarbij de matrixsleutel is een variabele, gebruik in dit geval een spatie. Dit voorbeeld moet dit duidelijk maken:

function my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_matrix) $ final_array = $ complete_array;  else $ key_1 = (integer) $ key_1; $ final_array [0] = 'dit'; $ final_array [$ key_1] = 'is'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'voorbeeld';  retourneer $ final_array; 

Naamconventies

Deze kan moeilijk zijn om aan te wennen, vooral als je uit verschillende omgevingen komt. In een notendop:

• Variabele namen zou moeten zijn allemaal in kleine letters, woorden gescheiden door onderstrepingstekens
• Klasse namen zou gebruiken woorden met hoofdletters gescheiden door onderstrepingstekens. Acroniemen zou alles moeten zijn hoofdletters
• constanten zou moeten zijn allemaal in hoofdletters, gespeerd door onderstrepingstekens
• Bestandsnamen zou moeten zijn allemaal in kleine letters, gescheiden door streepjes

Yoda-voorwaarden

Als u de voorwaarden andersom schrijft dan u gewend bent, worden parseerfouten voorkomen. Het ziet er een beetje raar uit, maar het is betere code.

if ('Daniel' === $ naam) echo 'Schrijf een artikel dat u wilt'; 

HTML

HTML kent niet zoveel regels, ik zou heel wat kunnen bedenken om dingen modulair te maken. Er zijn slechts vijf regels die u moet weten bij het schrijven van HTML:

1. Uw code moet geldig zijn voor de W3C-validator.
2. Zelfsluitende HTML-tags moeten exact één spatie bevatten vóór de schuine streep (dit is er een waar ik persoonlijk een hekel aan heb, maar het is een W3C-specificatie, niet alleen een irritatie van WordPress-huisdieren)
3. Attributen en tags moeten allemaal kleine letters zijn. De enige uitzondering is wanneer attribuutwaarden bedoeld zijn voor menselijke consumptie, in welk geval ze natuurlijk moeten worden getypt.
4. Alle attributen moeten een waarde hebben en moeten worden geciteerd (schrijven Is niet correct)
5. Inspringen moet worden bereikt met behulp van tabbladen en moet de logische structuur volgen.

CSS

CSS is een andere, losjes getypte taal, dus er is hier ook genoeg werk te doen. Maar toch, de normen gaan vrij gemakkelijk op coders.

selectors

Selectoren moeten zo gekwalificeerd zijn als nodig, leesbaar zijn voor iedereen, in kleine letters zijn met woorden gescheiden door streepjes en attribuutselectors moeten dubbele aanhalingstekens gebruiken. Hier is een beknopt voorbeeld:

invoer [type = "tekst"], invoer [type = "wachtwoord"], .name-field background: # f1f1f1; 

Eigendomsbestelling

De standaarden erkennen de behoefte aan wat persoonlijke ruimte hier omdat ze geen specifieke volgorde voor CSS-regels voorschrijven. Wat zij do zeggen is dat je een semantische structuur zou moeten volgen klinkt logisch. Groepeer eigenschappen op basis van hun relaties of groepeer ze op alfabetische volgorde, schrijf ze gewoon niet willekeurig op.

De grootste oorzaak voor willekeur is de “oh ik moet ook een marge toevoegen” en dan doorgaan om het onderaan toe te voegen. Neem de extra .3 seconden en voeg de regel toe op de logische plaats.

• tonen
• positionering
• Doosmodel
• Kleuren en typografie
• anders

.profile-modal display: block; positie: absoluut; left: 100px; top: 90px; achtergrond: # ff9900; kleur: #fff; 

Waardeopmaak

Dit is een plaats waar ik vooral een hekel heb aan het zien van inconsistenties. Als je de richtlijnen niet volgt, is dat nog steeds beter dan soms een spatie voor de waarde te zien; soms met behulp van steno, soms niet; soms met behulp van eenheden op 0 waarden, soms niet, enz.

Waarde-opmaak is behoorlijk complex, maar het komt vanzelf met wat oefening. Bekijk de exacte gids in de Codex voor het formatteren van uw waarden.

Javascript

In mijn ervaring is Javascript het meest geneigd om overal heen te gaan. Hoewel veel ontwikkelaars een aanzienlijke hoeveelheid Javascript kennen, werd het geleidelijk aan geleerd, als een bijzaak voor HTML, CSS en PHP. Wanneer u net begint met een nieuwe taal, maakt u veel meer fouten en als die fouten geen fatale fouten veroorzaken, kunnen ze in u worden geworteld.

In veel gevallen verwijzen de standaarden naar een lijnlimiet of -status “als een lijn niet te lang is”. Dit verwijst naar de jQuery-stijlgids die een a oplegt Limiet van 100 tekens op regels. De WordPress-gids is gebaseerd op de jQuery-handleiding, dus het is een goed idee om die ook te lezen.

puntkomma

Dit is de eenvoudigste regel, maar wordt vaak over het hoofd gezien. Laat nooit een puntkomma weg omdat uw code zonder deze code werkt. Het is gewoon slordig.

inspringen

Tabbladen moeten altijd worden gebruikt voor inspringen. U moet ook de inhoud van een sluiting inspringen, ook als de inhoud van een volledig bestand in één is opgenomen. Ik weet niet zeker waarom, maar een ongegronde sluiting op het hoogste niveau, mij afgeluisterd voordat ik de normen las.

Brekende lijnen

Wanneer u lange reeksen breekt, breek altijd de lijn na een operator, laat een variabele niet hangen. Dit maakt het op het eerste gezicht duidelijk dat de lijn verbroken is en dat je niet alleen een puntkomma bent vergeten.

Als een voorwaarde lang is, kunt u deze in meerdere regels splitsen en er een extra tabblad voor toevoegen. Deze ziet er heel raar uit, maar de scheiding die het toevoegt tussen de conditie en het lichaam is erg zichtbaar.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Deze regel bestaat uit' + n + 'woorden, dus het moet worden opgesplitst na' + 'een operator'; 

jQuery-iteratie

Volgens de normen jQuery-iteratie (JQuery.each ()) mag alleen worden gebruikt op jQuery-objecten. Je moet basic gebruiken voor, voor in, terwijl lussen in Javascript voor itereren over andere collecties.

Conclusie

Er is veel om op te merken en bij te houden en er is geen manier waarop iemand dit allemaal in één keer kan toepassen. U dient uw code zo dicht mogelijk bij de normen te houden en exact te volgen.

Naar mijn mening consistentie is de belangrijkste regel. Het is beter om consequent iets verkeerd te doen dan om halverwege te schakelen. Dit geldt vooral voor formatteringspraktijken, omdat deze geen invloed hebben op de functionaliteit van uw code en - voor het grootste deel - kan later eenvoudig in batch worden gewijzigd.

Heb je een hekel aan een element van de coderingsnormen, denk je dat er iets aan moet worden toegevoegd? Laat het ons weten in de comments!