Share
Een van de beste dingen over het leren van een nieuwe vaardigheid in software is dat je dit proces vaak ondergaat om iets te laten werken, te leren over enkele fouten die je hebt gemaakt, de code te verfijnen en het proces vervolgens te herhalen.
Uiteindelijk gaat het erom de kwaliteit van wat je doet te verbeteren, zodat het eindresultaat beter is dan het zou zijn geweest als je het als het ware in zijn eerste iteratie had achtergelaten.
En echt, als het gaat om het schrijven van software, is een van de dingen die we vaak horen en waarover we vaak praten, wel kwaliteit. Meer specifiek praten we over de kwaliteit van het gebouw in onze software.
Maar mijn gok is als je tien ontwikkelaars vraagt wat kwaliteit voor hen betekent, krijg je tien verschillende antwoorden.
Het woord "kwaliteit" biedt drie definities:
Als je even nadenkt over hoe dit zich verhoudt tot de producten die je bouwt met behulp van WordPress, wat komt er in je op?
Hoe dan ook, 'kwaliteit' kan verschillende dingen betekenen voor verschillende mensen. Maar ik geloof dat er bepaalde dingen zijn die niet subjectief zijn met betrekking tot de ontwikkeling van WordPress.
Voordat ik verder ga, zou ik willen opmerken dat wanneer ik iemand citeer, tenzij het een bekende bron is, ik de bron graag anoniem wil houden.
De reden is dat ik niet wil dat mensen die dergelijke tutorials lezen op de een of andere manier worden afgeleid en proberen een oplossing te vinden voor wat de persoon heeft gezegd. Het gaat om het punt, weet je?
En dat gebeurt. Ik spreek uit ervaring.
Met dat gezegd, onlangs iemand benaderde me over een stukje code die ik had verstrekt over het werken met WordPress haken bij het bouwen van thema's. Kort gezegd zeiden ze:
Meer coderegels zeggen is beter dan minder is iets wat alleen een hard-core, doorgewinterde WordPress-ontwikkelaar zou zeggen. Hoe minder code, hoe beter.
Voor hobbyisten en degenen die net het ontwikkelingsklimaat aan het leren zijn, kan ik zien hoe dit zou kloppen. Voor degenen die al een tijdje in het veld werken, herken je waarschijnlijk het probleem hiermee.
Ik beweer niet dat meer code altijd betere code is. Het is niet. In plaats daarvan suggereer ik dat er tijden zijn waarin een hele functie beter is dan een enkele regel code.
Hoe bouwen we dit op in ons eigen werk? Hoe kunnen we dit overbrengen op degenen die minder ervaren programmeurs zijn? Laten we een concreet voorbeeld bekijken en kijken of er iets te ontdekken valt.
In WordPress 4.4 is de ondersteuning voor title-tags zo gewijzigd dat je er ondersteuning voor hebt toegevoegd door simpelweg de volgende regel in je op te nemen functions.php het dossier:
Als u die functie niet wilt gebruiken, moet u de titel element in de kopsjabloon van uw thema.
Natuurlijk zijn er plug-ins en thema's die nog niet zijn bijgewerkt (ten tijde van deze tutorial). Daartoe is het nog steeds relatief gebruikelijk om iets te zien als de volgende regel code in sjabloonbestanden:
<?php wp_title("); ?>
Maar waarom zou iemand rotzooien met de titel? Denk aan SEO-plug-ins. Ze zullen vaak veranderen titel elementen om zoekmachine-vriendelijker te zijn.
Laten we eens kijken naar een voorbeeld uit de praktijk: stel dat u aan een thema en het bijbehorende thema werkt titel element bevat een oproep naar wp_title. Verder wil je dat zeker weten wp_title is filterbaar zodat andere code zoals de bovengenoemde plug-ins het kunnen bijwerken.
Het lijkt eenvoudig genoeg, toch? Maar laten we zeggen dat je het een beetje wilt aankleden door een scheidingsteken op te nemen en zijn positie bij te werken. In dit geval kunt u zoiets als dit doen:
<?php wp_title( '|', true, 'right' ); ?>
Of misschien wil je een stap verder gaan en de naam van de blog en de beschrijving ervan introduceren. Of misschien wilt u de titel zo instellen dat deze anders is op de startpagina.
Dan zou je zoiets als dit kunnen doen:
<?php bloginfo('name'); ?> | <?php is_home() ? bloginfo('description') : wp_title("); ?>
Afzonderlijk, buiten alle plug-ins of ander werk, ziet dit er goed uit. Het is een enkele regel code die hobbyisten kunnen gebruiken om hun uiteindelijke doel te bereiken.
Maar wat gebeurt er als iemand het thema verspreidt? Bovendien, wat gebeurt er wanneer iemand een plug-in wil gebruiken om de titel element?
Het zal niet werken.
Dit is slechts één reden waarom minder code niet altijd een betere code is en waarom minder code van mindere kwaliteit kan zijn.
Om ervoor te zorgen dat het gebruik van wp_title () is zo flexibel mogelijk, we moeten een aangepaste functie definiëren en deze filteren met behulp van de wp_title filter geleverd door WordPress:
Accentsconagua
= 2 || $ pagina> = 2) $ title = sprintf (__ ('Page% s', 'acme'), max ($ paged, $ page)). "$ sep $ title"; return $ title; De bovenstaande code is duidelijk meer code dan de enkele regel in het vorige voorbeeld, maar hij is ook flexibeler.
Eerst controleert de code of de pagina wordt weergegeven in een RSS-feed. Als dit het geval is, wordt alleen de opgegeven titel geretourneerd. Anders voegt het de naam van de titel toe aan het opgegeven $ title draad. Bij het bekijken van de startpagina of voorpagina plaatst de code de beschrijving na het scheidingsteken.
Ten slotte, als de gebruiker door de site paging, plaatst de code het paginanummer naar het scheidingsteken en de titel.
Dit biedt de basisfunctionaliteit voor het renderen van het titelelement binnen het thema. Dit is niet de standaardmanier om het voor alle thema's te doen, maar het is ongetwijfeld een betere manier om het te doen.
Als zodanig kunt u deze functie ook aanpassen aan wat u denkt dat het beste is voor uw eigen werk.
De belangrijkste afhaalmogelijkheid van deze tutorial is niet hoe je een filter instelt voor titels, of hoe je filters instelt, en ook niet hoe je met titels moet omgaan. behalve, wp_title wordt verouderd, zoals eerder vermeld in het artikel.
We eindigen met een aangepaste versie van de titel. We geven ontwikkelaars van derden ook de mogelijkheid om onze eigen code te overschrijven.
Hoewel dit meer code is, is het een oplossing van hogere kwaliteit.
Onthoud echter: dat is niet altijd het geval. Soms meer code kan kwaliteit verminderen en het kan verhoog de complexiteit. Maar dat is niet het punt van dit artikel. Misschien kan het het beste in een andere tutorial worden besproken.
In plaats daarvan is het doel van deze zelfstudie om te laten zien hoe minder code kan leiden tot een lagere kwaliteit en hoe meer code de kwaliteit kan verbeteren. Maar dit is geen vaste regel. Het hoort ook niet zo te zijn.
In plaats daarvan is het de bedoeling een denkwijze te introduceren door middel van wat kwaliteit definieert. Soms is minder code kwaliteitscode; soms is meer code kwaliteitscode.
Let bij het werken aan uw project niet op manieren om code te consolideren, alleen voor minder code. Zoek naar manieren om code te schrijven, zodat deze elegant, uitbreidbaar, leesbaar en onderhoudbaar is en vooral geschikt voor het doel.
Al het bovenstaande draagt samen bij aan de kwaliteit.
Als u op zoek bent naar voorbeelden van andere WordPress-projecten die kunnen worden gebruikt om de kwaliteit van de code te onderzoeken, te gebruiken in uw werk of in projecten van klanten, vindt u mogelijk ook iets interessants op de markt.
Als je geïnteresseerd bent in andere dingen die ik heb geschreven of geproduceerd voor Envato, kun je mijn werk bekijken op mijn profielpagina, en je kunt me volgen op mijn blog en / of Twitter op @tommcfarlin, waar ik het heb over softwareontwikkeling in de context van WordPress.
Aarzel niet om vragen of opmerkingen achter te laten in de feed hieronder, en ik zal ernaar streven om op elk van hen te reageren.
