Coderingsstandaarden voor WordPress [Guide]

De reden dat we helemaal codeerstandaarden hebben (niet alleen voor WordPress) is om een ​​vertrouwde omgeving te creëren voor programmeurs die 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 gebruikt geen MVC-patroon. Projecten die zonder uitzondering een OOP- en MVC-richtlijn volgen (zoals Laravel), hebben consistentie en best practices "ingehaald" vanwege hun structuur.

WordPress is helaas rijp voor spaghetti-codering, oftewel 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 wat meer 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 u gelijk of ongelijk heeft, 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 codeerstijl 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 onjuist is dan iets dat soms juist is en soms niet. Je kunt altijd een script schrijven om dingen in één keer te veranderen, of je code aan het einde doorlezen.

Het volgen van standaarden is moeilijk ! Het plaatsen van een accolade op dezelfde regel als de functie in plaats van een regel hieronder is vrij eenvoudig, zelfs als je gewend bent om enter te raken. Wanneer u echter aan 100 kleine regels moet denken, wordt het hele proces een beetje foutgevoelig. Ondanks mijn harde houding ten aanzien van het naleven van normen ben ik even schuldig als iemand anders over het maken van fouten. Aan het eind 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 heb ik een aantal fragmenten uit de vier talen naar voren gebracht, die ik regelmatig tegenkom 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 verklaringen 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 ingepakte code (ik heb een slecht gezichtsvermogen), dus dit is er een die ik vooral graag afdwing. Zet spaties na komma's en aan beide zijden van logische, vergelijking, string en toewijzingsoperators, na if, elseif, for, foreach en switch- instructies enzovoort.

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

Een nogal verwarrende uitzondering op de uitzondering is arrays waarbij de array-sleutel een variabele is, gebruik in dit geval een spatie. Dit voorbeeld zou dit duidelijk moeten maken:

 function my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') {if (null == $ complete_array) {$ 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 moeten allemaal kleine letters zijn, woorden gescheiden door underscores
• Klassenamen moeten hoofdletters gebruiken, gescheiden door onderstrepingstekens. Acroniemen moeten allemaal in hoofdletters zijn
• Constanten moeten allemaal in hoofdletters zijn, onderbroken door onderstrepingstekens
• Bestandsnamen moeten allemaal kleine letters zijn, 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 kennen 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 zijn bedoeld 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 aan de winkel. Toch gaan de normen vrij gemakkelijk over codeurs.

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; } 

Eigenschap Bestelling

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

De grootste reden voor willekeur is de "oh ik moet ook een marge toevoegen" en dan doorgaan met 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 plek 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, etc.

Waarde-opmaak is behoorlijk complex, maar het komt vanzelf met wat oefening . Bekijk de exacte handleiding 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 dit geleidelijk aan geleerd, als een bijzaak voor HTML, CSS en PHP. Wanneer je net begint met een nieuwe taal, maak je veel meer fouten en als die fouten geen fatale fouten veroorzaken, kunnen ze in je ingebakken raken.

In veel gevallen verwijzen de standaarden naar een lijnlimiet of -status "als een lijn niet te lang is". Dit verwijst naar de jQuery Style Guide die een limiet van 100 tekens op regels oplegt. 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 laten 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 irriteerde me nog voordat ik de normen las.

Brekende lijnen

Bij het breken van lange reeksen moet je altijd de lijn breken 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 aan toevoegen. Deze ziet er heel raar uit, maar de scheiding die het toevoegt tussen de conditie en het lichaam is heel goed 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 standaarden moet jQuery-iteratie (jQuery.each()) alleen worden gebruikt op jQuery-objecten. Je moet basis gebruiken voor, voor / in, while- lussen in Javascript voor het itereren van andere collecties.

Conclusie

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

Naar mijn mening is consistentie de belangrijkste regel . Het is beter om consequent iets verkeerd te doen dan om halverwege te schakelen. Dit geldt met name voor formatteringspraktijken, omdat deze geen invloed hebben op de functionaliteit van uw code en - voor het grootste deel - later eenvoudig in een batch kunnen 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 reacties!

Showcase van 40 dikke en prachtige geïllustreerde websites

Illustraties voegen karakter en levendigheid toe aan uw site. Kleuren, karikaturen en creativiteit die worden omgezet in vetgedrukte illustraties kunnen de indruk van een gebruiker van uw website wijzigen en natuurlijk uw bezoekers op verschillende manieren beïnvloeden. Illustraties kunnen uw website ook echt uniek maken en u kunt het gebruiken als een platform om uw persoonlijke branding te lanceren .

(Technische en ontwerptips)

Zoek Emoji's in Gboard met Doodles

Gboard voor Android-gebruikers hoeft niet langer door de hele emoji-bibliotheek te bladeren om die specifieke te vinden die ze nodig hebben als een update Google heeft het toetsenbord ingeschakeld om emoji-zoekopdrachten een stuk eenvoudiger te maken .Dus hoe verbeterde Google de emoji-zoekopdracht? Door de kracht van doodles te gebruiken

(Technische en ontwerptips)