Share
Als het gaat om het schrijven van een serie blogposts, is een van de meest uitdagende aspecten als lezer het bijhouden van elke post die wordt gepubliceerd.
Zelfs als het je lukt om het bij te houden, kunnen berichten die meer dan 1.000 woorden bevatten - met name die met code - tijd kosten die velen van ons niet hebben, vooral als het gaat om het jongleren met ons werk, thuislevens, hobby's en andere dingen.
Dus om ervoor te zorgen dat de informatie die in deze serie wordt gepresenteerd nog steeds op een begrijpelijke manier wordt gepresenteerd, dacht ik dat ik zou experimenteren met een samenvatting van de hele serie. Op die manier, voor degenen onder u die een artikel hebben gemist of niet de tijd hebben gehad om te gaan zitten en elk artikel te doorlopen, kan nog steeds de kern van elk punt in de artikelen worden vermeld.
Met dat gezegd, laten we eens kijken naar alles wat we hebben besproken bij het bekijken van de WordPress coderingsstandaarden.
Over het algemeen is het doel van deze hele serie om te helpen licht te brengen in de WordPress Coderingsnormen, zodat degenen die niet van hen hebben gehoord, degenen die zich er niet van bewust zijn, of degenen die ze niet hebben gevolgd, beter uitgerust zijn om te schrijven WordPress-thema's, plug-ins en applicaties.
Om dit te doen, hebben we in zes verschillende artikelen een grondige duik genomen in een aantal verschillende aspecten van de coderingsnormen, met aandacht voor principes, beste praktijken en dingen die moeten worden vermeden.
Hieronder hebben we elk van de artikelen en de opsommingspunten samengevat die belangrijke punten zijn en het vermelden waard zijn voor het betreffende onderwerp. Als u meer informatie wilt, kunt u natuurlijk teruggaan naar het artikel in de serie (bovenaan dit bericht) om het volledig te lezen.
Wanneer u werkt met klassen, functies, variabelen, attributen of argumenten, kunnen naamgevingsconventies helpen om het doel dat ze dienen te verduidelijken.
Klassen zijn bijvoorbeeld over het algemeen zelfstandige naamwoorden en functienamen zijn doorgaans werkwoorden. Uiteindelijk gaat het erom ervoor te zorgen dat de code leesbaar en onderhoudbaar is.
Rechtstreeks van de coderingsnormen:
Afkorting van variabelenamen niet noodzakelijkerwijs afkorten; laat de code ondubbelzinnig zijn en zelfdocumenteren.
Maar dit specifieke principe is de moeite van het volgen waard achteloos van waar in de code je werkt.
Houd er rekening mee dat als het gaat om het doorgeven van functieargumenten, het belangrijk is om te onthouden dat als een functienaam de actie beschrijft die deze uitvoert binnen de context van de klasse, het argument moet weergeven wat de functie feitelijk doet.
Geef de voorkeur aan tekenreekswaarden op recht
waarenvalsbij het aanroepen van functies.
Dit betekent dat functieargumenten duidelijke waarden moeten zijn - strings of getallen - omdat booleaanse waarden vaak onduidelijk zijn en niet noodzakelijk aangeven welke actie de functie zal uitvoeren.
Als het gaat om het werken met strings in WordPress, is het typisch een kwestie van werken binnen de nuances van PHP's stringmanipulatie. Daarom hebben we in dit artikel besproken hoe PHP offertes verwerkt (zowel single als double) en hoe dit onze WordPress-ontwikkeling beïnvloedt..
De eenvoudigste manier om een tekenreeks in PHP te definiëren is om deze te omsluiten met enkele aanhalingstekens (dat wil zeggen, het 'teken').
Zoals bij de meeste programmeertalen, daar zijn manieren om te ontsnappen aan personages, zodat je een letterlijke tekst kunt opschrijven. Als u bijvoorbeeld wilt schrijven: "String in PHP is eenvoudig", als een tekenreeks, kunt u dit doen:
'String \' s in PHP zijn eenvoudig. '
De backslashes geven PHP de opdracht om het enkele citaat uit te schrijven in plaats van de eigenlijke reeks te beëindigen. Het tweede ding om op te merken is dat als je een variabele hebt, dat zal doen niet vervangen als deze tussen enkele aanhalingstekens wordt geplaatst.
Dubbele aanhalingstekens werken een beetje anders binnen PHP. Concreet:
Als de string tussen dubbele aanhalingstekens staat ("), interpreteert PHP meer escape-sequences voor speciale tekens.
Dit betekent dat als u een variabele insluit in een dubbele genoteerde PHP-reeks, de variabele wordt geïnterpreteerd en de waarde ervan wordt ingevoegd in plaats van de variabele voordat deze wordt weergegeven op het scherm.
Omdat veel van het werk in WordPress ook het opschrijven van markeringen omvat binnen een PHP-string, is het het beste om die strings in enkele aanhalingstekens te plaatsen, zodat de attributen van het HTML-element tussen dubbele aanhalingstekens kunnen staan.
Maar er zijn tijden waar het meer de voorkeur heeft om dubbele aanhalingstekens te gebruiken vooral wanneer u een variabele moet evalueren.
Het beste advies dat hier kan worden gegeven is om te weten hoe enkele aanhalingstekens en dubbele aanhalingstekens werken binnen PHP, en ze vervolgens op de juiste manier te gebruiken op basis van uw use-case.
Let op: witte ruimte verbetert de leesbaarheid van code en als ontwikkelaars is een van onze belangrijkste doelen om ervoor te zorgen dat de code die we schrijven niet alleen een vooraf gedefinieerde standaard volgt, maar ook catering biedt aan andere ontwikkelaars voor leesgemak en onderhoudbaarheid.
Wat indentatie betreft, is er niets echt nieuws, vooral als je bekend bent met talen in C-stijl. Meestal zal je elke keer inspringen als je een nieuw blok begint.
Merk op dat de coderingsnormen do hebben regels over tabbladen en spaties:
Uw inspringing moet altijd een logische structuur weergeven. Gebruik echte tabbladen en geen spaties, omdat dit de meeste flexibiliteit tussen klanten mogelijk maakt.
Dit is vooral handig in de open-sourcecommunity.
Spaties moeten op de volgende plaatsen worden geplaatst:
Accentsconagua
||, &&, en !)<, >, ==, ===, enz.)=)Dit is een van de eenvoudigste conventies die je moet volgen. Eerlijk gezegd is de kans groot dat uw IDE of editor naar keuze deze functie ingebouwd heeft, of dat er een plug-in beschikbaar is waarmee u dit automatisch kunt doen.
Als dit niet het geval is, moet u de mogelijkheid hebben om tabs, spaties, regelterugloop enzovoort te bekijken, zodat u eenvoudig kunt identificeren waar de achterliggende spaties zijn. En als je ze ziet, elimineer ze dan.
In deze sectie hebben we gekeken naar waarom stijl ertoe doet. We hebben ook precies gedefinieerd hoe coderingsstandaarden en conventies definiëren hoe we stylen onze code.
Over het algemeen zijn de regels eenvoudig:
Deze komen met name vaak voor als je uit andere C-stijl talen komt; echter, net zoals WordPress subtiele nuances heeft die andere talen niet hebben, is het de moeite waard ze hier te markeren.
PHP biedt verschillende manieren om met reguliere expressies te werken, hoewel WordPress aanbeveelt om slechts een handvol van de beschikbare functies te gebruiken.
De regels voor het werken met reguliere expressies in PHP in WordPress zijn als volgt:
preg functies die PHP biedt\ e schakelaar die aangeboden wordt door PHP - gebruik preg_replace_callback in plaats daarvan.In het bijzonder raad ik aan bekend te zijn met de volgende functies:
preg_replacepreg_matchpreg_match_allMerk bovendien op dat preg_replace_callback een manier is om een functie aan te roepen wanneer een reguliere expressie een overeenkomst heeft gevonden.
Er is een zeer eenvoudige vuistregel voor het gebruik van PHP-tags in WordPress-ontwikkeling:
Dit betekent dat je nooit een bestand of een inline PHP-statement mag openen of met . Uiteraard moeten alle inline PHP-verklaringen worden beëindigd met de ?> afsluitende tag.
Naast de coderingsstandaard die hierboven is gedefinieerd, zou ik ook toevoegen:
De reden hiervoor is woordelijk genoemd in het bijbehorende artikel:
Maar als u een plug-in of een toepassingsbestand schrijft dat 100% PHP is, hoeft u aan het einde van het bestand geen afsluitende tag toe te voegen. De parser zal het zelf kunnen detecteren, en als jij do een afsluitende tag bevatten, dan kunt u mogelijk witruimte overhouden aan het einde van het bestand dat allerlei problemen kan oproepen als het tijd is om de plug-in te activeren.
Als het gaat om het schrijven van op WordPress gebaseerde code, zeggen de coderingsstandaarden dat we moeten streven naar leesbaarheid:
Over het algemeen is leesbaarheid belangrijker dan slimheid of beknoptheid.
Sommige ontwikkelaars beschouwen de ternaire operator als een beetje in tegenspraak met dit specifieke principe, specifiek omdat het nog een andere manier is om een if / else uitspraak. Zelfs dan nog, de ternaire operator is een haalbare optie als het gaat om het schrijven van eenvoudige conditionals en staat vermeld in de WordPress coderingsstandaarden.
Ten eerste, voor degenen die niet vertrouwd zijn, is de ternaire operator een vereenvoudigde manier van schrijven if / else voorwaardelijke verklaring. Het wordt meestal gebruikt enkel en alleen wanneer de voorwaardelijke is van de eenvoudigste vorm en enkel en alleen wanneer er een single is als en een single anders blok.
$ uses_gasoline = 'hybrid' == $ car_type? false: true; echo $ uses_gasoline;
Een belangrijk ding om op te merken: de ternaire operator test op waar (in plaats van fout, uiteraard).
Yoda-voorwaarden verwijzen naar de omkering van vergelijkingen tussen variabelen en waarden die we uitvoeren bij het schrijven van WordPress-code. Wij dit, volgens de coderingsnormen, omdat:
Als u in het bovenstaande voorbeeld een gelijkteken weglaat (geef toe, het gebeurt zelfs voor de meest doorgewinterde mensen), krijgt u een ontleedfout, omdat u niet kunt toewijzen aan een constante zoals
waar. Als de verklaring andersom was($ the_force = true), de opdracht zou volkomen geldig zijn, terugkeren1, waardoor de if-opdracht wordt geëvalueerdwaar, en je zou een tijdje achter die bug kunnen zitten.
Natuurlijk, het is discutabel, maar het is onderdeel van de standaard en jij zijn gaan zien gebruikt door WordPress kern, thema's, plug-ins, artikelen en meer.
Kortom, als de API niet voldoet aan wat u nodig heeft, dan $ wpdb is misschien de beste optie, maar ik raad u aan deze alleen te gebruiken als u de rest van uw opties hebt uitgeput.
In WordPress zijn er een aantal API's die het ons mogelijk maken om onze eigen query's te maken zonder dat er SQL hoeft te worden geschreven. Sommige van deze API's omvatten:
WP_QueryWP_User_Queryget_post_metaget_comment_metaget_user_metaHet is belangrijk om vertrouwd te raken met wat de API biedt, zodat u weet of er al dan niet een functie of een object beschikbaar is om te gebruiken om meteen uw eigen zoekopdrachten te schrijven..
API's kunnen niet voorspellen allemaal gevallen waarin we onze databasequery's moeten schrijven. En in die situaties biedt WordPress een object waarmee we rechtstreeks kunnen communiceren met de database: $ wpdb.
Het stelt ons in staat om:
SELECT variabelen, rijen, kolommen en generieke resultatenINSERT rijenBIJWERKEN bestaande rijenEn sta ons toe om de gegevens op te halen in een indeling waarmee we het liefst werken: een array, een object of een enkele waarde (in sommige gevallen) en stelt ons zelfs in staat onszelf te beschermen door middel van SQL-injectie.
Maar onthoud:
Als u de database moet aanraken, neem dan contact op met sommige ontwikkelaars door een bericht te plaatsen op de mailinglijst van wp-hackers. Misschien willen ze een functie voor de volgende versie van WordPress maken om de gewenste functionaliteit te dekken.
Zoals ik eerder al zei, kan het moeilijk zijn om een reeks artikelen bij te houden, vooral die met code. Daartoe wilde ik experimenteren met het geven van een samenvatting van de serie die nog steeds voldoende informatie geeft aan degenen die geen kans hebben gehad om de hele serie bij te houden, maar die nog steeds geïnteresseerd zijn in de onderwerpen die bij de hand zijn..
Dus als deze specifieke strategie of type artikel iets is waarvan je geniet, laat het me weten en misschien kunnen we dit ook doen voor andere series; anders geen schade geen fout - het gaat mij in beide gevallen goed.
Hoe dan ook, ik hoop dat de serie heeft geholpen een aantal verschillende gebieden van de WordPress-coderingsstandaarden expliciet te maken die je eerder hebt gemist, verkeerd hebt begrepen of niet volledig hebt gegroet tot het lezen van deze artikelen.
