Share
På den här webbplatsen spenderar vi mycket tid vid delning av information och diskuterar hur du utför vissa saker med WordPress. Trots allt, syftet med webbplatsen är att ge handledning - det vill säga, vi försöker ge praktiska råd om hur man bygger vissa saker med hjälp av plattformen.
Men utveckling handlar inte helt om att skriva kod och bygga saker. Det handlar också om att skriva kvalitet, underhållsbar kod, refactoring och förbättra tillståndet för våra projekt och försöker i allmänhet lämna en kodbas i ett bättre tillstånd än det var när vi hittade det (eller när vi började skapa det).
Så istället för att fokusera på hur man bygger något eller granskar någon särskild kod, låt oss se några praktiska tips för att skriva kvalitets WordPress-kod.
Först och främst - och även om vi diskuterar det här mycket - det är värt att upprepa om och om igen:
Följande WordPress-kodningsstandarder är en av de viktigaste sakerna du kan göra när du skriver dina teman, plugins eller program.
För de som är obekanta, innehåller WordPress Coding Standards regler för hur vi ska formatera vårt WordPress-baserade PHP. Naturligtvis finns det ingenting att faktiskt förstärka reglerna - du kan ignorera dem (och många gör), men det anses vara en bra metod för dem som ser på att utveckla WordPress-baserade projekt och det respekteras av dem som är aktiva i samhället.
Vidare innebär följande kodningsstandarder att vi - tillsammans med alla andra utvecklare som också gör det - kommer att ha liknande kod. Faktum är att ett av målen för definierade kodningsstandarder är så att koden ser ut som den har skrivits av en enda utvecklare.
En annan fördel med att göra detta är att det också gör det enkelt för andra att bidra till vårt kodbas. När allt eftersom WordPress och dess derivatverk är öppen källkod kanske andra vill komma med och gaffla eller bidra till att ge dem möjlighet att enkelt läsa vår kod.
Slutligen är det inte nödvändigtvis ett uppmaning att gå tillbaka och refaktera allt du har gjort. Nu är det lika bra en tid som någon att börja följa standarderna. Bra utvecklare förbättras hela tiden, så det är helt acceptabelt att börja nu (även om det är mitt i ett projekt).
En av de mest användbara sakerna du kan göra när du skriver kod är att lämna användbara kommentarer som förklarar exakt vad det är du försöker göra.
Naturligtvis kan kommentarer ligga på klassnivå, funktionsnivå och linjenivån. De är tillåtna i PHP, HTML, JavaScript och CSS så det finns verkligen ingen ursäkt inte att inkludera dem någonstans.
Visst, att skriva kommentarer tar lite extra tid, men kom ihåg att om det var lätt att läsa skulle det inte kallas kod.
Tänk på det på så vis: Programmerare är berömda för att gå tillbaka till sina tidigare projekt och erkänna hur dåligt deras kod är, eller hur skulle vi göra något annorlunda om vi arbetade på det här projektet nu.
Om vi säger det om vår egen kod, vad måste andra tänka när de ser vår kod, speciellt om de kommer från en mer erfaren bakgrund?
För mer djupgående tankar om att kommentera både server-sida och klientsidkod, se till att du granskar den här serien.
En annan sak som vi utvecklare kan göra är att förenkla våra funktioner. Även om jag inser att det här är något av ett subjektivt område, tror jag att det syftar till mindre, mer fokuserade funktioner gör koden mer läsbar och kan i sista hand hjälpa till med testbarhet (om du är intresserad av att gå den vägen).
För det första är det inte ovanligt att se funktioner som överstiger 30, 40 eller 50 linjer. Problemet är att dessa funktioner ofta gör mer än en sak.
Detta är problematiskt eftersom:
Så med det sagt finns det några praktiska tips som vi kan följa för att förbättra kvaliteten på våra funktioner.
Om du befinner dig att skriva samma sak om och om mellan olika funktioner, så är det ett fall för när du behöver extrahera den specifika delen av koden och flytta den till sin egen funktion så att den kan kallas av alla de platser som det existerar för närvarande.
Om du tycker att din kod är komplicerad att beskriva med kommentarer eller svår att spåra medan du läser igenom det kan det vara värt att ta ett steg tillbaka och refactoring din kod till något lite enklare.
Det ser annorlunda ut i varje situation, men strävar efter läsbarhet över komplexitet är ofta gånger ett bättre mål att sträva efter snarare än att bara få något att fungera.
Detta är förmodligen den mest subjektiva punkten, jag tycker att det är värt att föra upp och det är helt enkelt att vi bör sträva efter att hålla våra funktioner små med 20 linjer långa som är relativt långa för att kunna sikta. Visst kan detta vara något av en utmaning med det sätt som WordPress ofta kräver att vi skapar stora arrays för att passera som argument, men du får idén: behåll dem små, fokuserade och underhållbara.
Ja, detta kommer att resultera i fler funktioner, men koden blir lättare att läsa och underhålla eftersom varje funktion har ett enda specifikt syfte. Det betyder att du kan namnge dem med större tydlighet och ge enhetstester runt dem lättare.
Det är uppenbart att inget av ovanstående är hårda regler som måste följas - de är helt enkelt förslag på hur man förbättrar kvaliteten på koden som vi skriver, som vi upprätthåller, och att vi bidrar till andras arbete.
Ovanför tror jag att vi bör sträva efter läsbarhet och testbarhet. Att hålla de två målen är framkanten av vårt arbete kommer att hjälpa till att köra allt annat till sin rätta plats.
Det här är naturligtvis inte en komplett lista - det är långt ifrån det! Så snälla erbjuda dina förslag i kommentarerna!
Accentsconagua