Share
Op deze site besteden we veel tijd aan het delen van informatie en bespreken we hoe we bepaalde dingen met WordPress kunnen bereiken. Immers, het doel van de site is om tutorials te geven - dat wil zeggen, we proberen praktisch advies te geven over hoe bepaalde dingen te bouwen met behulp van het platform.
Maar ontwikkeling gaat niet strikt over het schrijven van code en het bouwen van dingen. Het gaat ook om schrijfkwaliteit, onderhoudbare code, refactoring en het verbeteren van de status van onze projecten, en in het algemeen proberen om een codebase in een betere staat achter te laten dan toen we hem ontdekten (of toen we hem begonnen te maken).
Dus in plaats van ons te concentreren op hoe iets te bouwen of een bepaalde code te herzien, bekijken we een paar praktische tips voor het schrijven van kwaliteit WordPress-code.
Eerst en vooral - en hoewel we dit vaak bespreken - is het de moeite waard om het steeds opnieuw te herhalen:
Het volgen van de WordPress coderingsstandaarden is een van de belangrijkste dingen die je kunt doen als je je thema's, plug-ins of applicaties schrijft.
Voor degenen die onbekend zijn, bieden de WordPress coderingsstandaarden regels voor hoe we onze op WordPress gebaseerde PHP moeten opmaken. Natuurlijk is er niets om echt te doen afdwingen de regels - je kunt ze negeren (en veel doen), maar het wordt als een goede methode beschouwd voor degenen die serieus bezig zijn met het ontwikkelen van op WordPress gebaseerde projecten, en het wordt gerespecteerd door degenen die actief zijn in de gemeenschap.
Verder betekent het volgen van coderingsstandaarden dat wij - samen met alle andere ontwikkelaars die het ook doen - een vergelijkbare code hebben. In feite is een van de doelen van gedefinieerde coderingsnormen dat de code lijkt te zijn geschreven door een enkele ontwikkelaar.
Een ander voordeel om dit te doen is dat het het ook gemakkelijk maakt voor anderen om bij te dragen aan onze codebase. Omdat WordPress en zijn afgeleide werken immers open source zijn, willen anderen misschien mee willen gaan en bijdragen, waardoor ze uiteindelijk de mogelijkheid hebben om onze code gemakkelijk te lezen..
Ten slotte is dit niet noodzakelijkerwijs een oproep tot actie om terug te gaan en alles wat je hebt gedaan te refactoren. Het is nu net zo goed om de norm te volgen. Goede ontwikkelaars verbeteren de hele tijd, dus het is volledig acceptabel om nu te beginnen (zelfs als het midden in een project zit).
Een van de meest nuttige dingen die je kunt doen als je code schrijft, is om nuttige opmerkingen achter te laten die precies uitleggen wat je probeert te doen.
Uiteraard kunnen opmerkingen op klasniveau, functieniveau en het lijnniveau leven. Ze zijn toegestaan in PHP, HTML, JavaScript en CSS, dus er is echt geen excuus niet om ze ergens op te nemen.
Natuurlijk, het schrijven van opmerkingen kost wat extra tijd, maar vergeet niet dat als het gemakkelijk te lezen was, het geen code zou worden genoemd.
Denk er op deze manier over na: programmeurs zijn berucht omdat ze teruggaan naar hun vorige projecten en herkennen hoe slecht hun code is, of hoe we iets anders zouden doen als we nu aan dat project bezig waren.
Als we dat zeggen over onze eigen code, wat moeten anderen dan denken als ze onze code zien, vooral als ze afkomstig zijn van een meer ervaren achtergrond?
Voor meer diepgaande gedachten over het geven van commentaar aan zowel server- als client-side code, moet u deze serie doornemen.
Een ander ding dat wij ontwikkelaars kunnen doen, is om onze functies te vereenvoudigen. Hoewel ik me realiseer dat dit enigszins een subjectief gebied is, denk ik dat het streven naar kleinere, meer gerichte functies de code leesbaarder maakt en uiteindelijk kan helpen met de toetsbaarheid (als je geïnteresseerd bent om die route te gaan).
Ten eerste is het niet ongebruikelijk om functies te zien die hoger zijn dan 30, 40 of 50 regels. Het probleem is dat deze functies vaak meer dan één ding doen.
Dit is problematisch omdat:
Dus, met dat gezegd, zijn er enkele praktische tips die we kunnen volgen om de kwaliteit van onze functies te verbeteren.
Als je merkt dat je steeds hetzelfde schrijft over verschillende functies, dan is dat het geval wanneer je dat specifieke deel van de code moet extraheren en verplaatsen naar zijn eigen functie zodat het kan worden opgeroepen door alle plaatsen die het bestaat op dit moment.
Als je merkt dat je code gecompliceerd is om te beschrijven met opmerkingen of moeilijk te traceren is tijdens het doorlezen, is het misschien de moeite waard om een stapje terug te doen en je code opnieuw in te stellen naar iets eenvoudiger.
Dit ziet er in elke situatie anders uit, maar streven naar leesbaarheid boven complexiteit is vaak een beter doel om naar te streven in plaats van gewoon iets te laten werken.
Dit is misschien wel het meest subjectieve punt, ik denk dat het de moeite van het brengen waard is en dat is gewoon dat we ernaar moeten streven onze functies klein te houden met 20 lijnen lang, een relatief solide lengte om naar te streven. Natuurlijk kan dit een beetje een uitdaging zijn met de manier waarop WordPress ons vaak vraagt om grote arrays te maken om als argumenten door te geven, maar je krijgt het idee: houd ze klein, gericht en te onderhouden.
Ja, dit zal resulteren in meer functies, maar de code zal gemakkelijker te lezen en te onderhouden zijn omdat elke functie een specifiek doel heeft. Dit betekent dat u ze met meer duidelijkheid kunt benoemen en eenheidstests om hen heen gemakkelijker kunt uitvoeren.
Vanzelfsprekend zijn geen van de bovenstaande harde regels die moeten worden opgevolgd - het zijn gewoon suggesties voor het verbeteren van de kwaliteit van de code die we schrijven, die we bijhouden en die we bijdragen aan het werk van anderen.
Bovenal geloof ik dat we moeten streven naar leesbaarheid en toetsbaarheid. Het houden van die twee doelen zijn de voorhoede van ons werk en helpen al het andere op zijn juiste plaats te brengen.
Dit is natuurlijk geen volledige lijst - het is verre van dat! Dus bied je suggesties aan in de comments!
Accentsconagua