Skriver bättre WordPress-kod: PHPStan
I det senaste inlägget i den här serien (som visserligen är ett tag sedan) pratade jag länge om Composer och dess låsfil.
Jag rekommenderar att du läser de två föregående artiklarna eftersom Composer så småningom kommer att spela en roll i detta material som detta och framtida inlägg kommer att dela. Men om du väljer att inte komma ikapp dem (eller redan är bekant med Composer) så är kärnan i de tidigare inläggen följande:
Jag rekommenderar inte att du kontrollerar leverantörskatalogen i ditt arkiv. Det kan bli en enorm katalog senare, och det kan undergräva hela syftet med Composer.
Målet är att se till att alla kör samma version av projektets beroenden – inte äldre versioner, inte nyare versioner – utan samma version.
Med det sagt finns det många beroenden eller paket som vi kan installera som hjälper oss att se till att vi skriver högsta möjliga kvalitetskod.
Visst, några av dessa kan vara i form av något som kodningsstandarder, men det är egentligen fler regler än vad de är element för att skriva högkvalitativ kod (även om jag inte tycker att de ska lämnas utanför diskussionen – bara utelämnas vid den här tiden 🙃).
Tillbaka till verktygen i fråga: Vilka är några verktyg som hjälper till att skriva högkvalitativ WordPress-kod? Jag ska dela med mig av några av mina favoriter och dem ska jag prata om hur vi kan köra dem alla mot en kodbas.
Låt oss först ta en titt på statisk analys med PHPStan.
Bättre WordPress-kod med PHPStan
Vad är statisk analys, egentligen?
Först några ord om statisk analys. Nämligen, vad är det? Det är en munsbit, för en sak:
Statisk kodanalys (även känd som källkodsanalys) utförs vanligtvis som en del av en kodgranskning (även känd som white-box-testning) och utförs i implementeringsfasen av en säkerhetsutvecklingslivscykel (SDL).
Statisk kodanalys hänvisar vanligtvis till användningen av verktyg för statisk kodanalys som försöker lyfta fram möjliga sårbarheter i "statisk" (icke-körande) källkod genom att använda tekniker som Taint Analysis och Data Flow Analysis.
Tänk på det så här: Det är ett sätt att analysera ett program för potentiella fel som du kanske inte ser när du arbetar med kodbasen.
Det vill säga att det finns problem, buggar, säkerhetsproblem som kan finnas men som du inte kan upptäcka av ett antal anledningar (den minsta är att du är för nära koden).
Med tiden har dock utvecklingsgemenskapen lärt sig sätt att analysera kod, generera uppsättningar regler och bygga verktyg för att hitta exakt allt ovanstående.
Statisk analys av WordPress-centrerad kod
Och det är här PHPStan kommer in i bilden.
Som nämnts är målet med paketet att identifiera fel eller buggar som finns i din kod innan din kod används av någon annan än utvecklare, markera dem och ge dig möjlighet att fixa dem.
Eftersom verktyg som detta undersöker en kodbas (mot att köra koden), är det inte alltid möjligt att få en tydlig bild. Det betyder att vi kan få falska positiva resultat.
Mer om detta om ett ögonblick dock.
Om du är intresserad av att komma igång med att köra PHPStan mot din kodbas är det enkelt. När du har installerat det, kom bara ihåg att konfigurera det så att det inte ser ut i vendorkatalogen eller, säg, WordPress-kärnan.
Låt den istället undersöka din kod.
Installerar PHPStan
Lägg först till följande rad i sektionen i din composer.jsonfil :require-dev
"phpstan/phpstan": "^0.11.12"
Kör sedan composer updatei din terminal.
När den väl har installerats kan du köra den mot en enskild fil, en katalog eller en uppsättning kataloger. Om du har läst mina tidigare inlägg om kodorganisation, så vet du att jag är ett fan av att behålla majoriteten av projektets källkod i srcdig kan köra något så här:
$ vendor/bin/phpstan analyse src
Detta kommer att generera utdata baserat på vad verktyget hittar.
Kommer du ihåg tidigare när jag sa att det kan hitta saker som falska positiva? Här är en mer detaljerad sammanfattning av vad du kan se:
- Extra argument som skickas till funktioner (t.ex. funktion kräver två argument, koden skickar tre)
- Extra argument som skickas till print/sprintf-funktioner (t.ex. formatsträng innehåller en platshållare, koden skickar två värden för att ersätta)
- Uppenbara fel i död kod
- Magiskt beteende som måste definieras.
Allt ovanstående direkt från förvaret.
Det är här regelnivåer kan göra stor skillnad, även om det kan kräva lite justeringar för att få det till en nivå som är precis rätt för ditt team eller ditt projekt.
Vad sägs om analys för WordPress?
Viktor Szépe delade den här resursen med mig (något han faktiskt har skrivit) och jag tycker att det är något relevant och användbart. Tanken med paketet är enkel:
Det löser alla problem jag hade under analys av kod för WordPress.
Inte illa, eller hur?
Analysera din kod
Oavsett ditt projekt, din kodorganisation eller på vilken nivå du kör just detta verktyg, är poängen alltid att förbättra kvaliteten på vi skriver WordPress-kod.
Att installera detta som ett Composer-paket och sedan köra det mot din srckatalog är ett steg i rätt riktning.
Som tidigare nämnts kommer jag att dela med mig av några andra verktyg och jag kommer sedan att dela hur man kör dem alla mot en kodbas innan jag överför koden till ett arkiv.
Notera
Om du har problem med att försöka konfigurera paketet, kontaktade Dave Mackey mig med ett liknande problem och dess lösning.