Grundläggande kodningsstandarder via PSR-1
Igår pratade jag kort om en motivering för att använda PSRs kontra WordPress-kodningsstandarderna och när och varför för båda. Men det betyder inte att det inte är utan dess förvirringspunkter, särskilt om du bara börjar med dem, eller hur?
Med det menar jag: Säg att du har arbetat med WordPress-kodningsstandarderna i åratal (eftersom jag kan relatera) och nu finns det en helt ny uppsättning regler och riktlinjer att följa. Men det är inte som en enkel fråga att ändra lite blanksteg och byta namn på filer.
Det finns andra punkter att följa, och var och en beskrivs i ett antal, helt bokstavligen (PSR-1, PSR-2, och så vidare), av hur något ska fungera.
Så när det gäller bara de grundläggande kodningsstandarderna som beskrivs i PSR-1, vilka är några problematiska områden som vi kan stöta på som WordPress-utvecklare?
Grundläggande kodningsstandarder (och biverkningar)
Jag har inga planer på att gå igenom vart och ett av dokumenten och återskapa vad vi redan kan lära oss genom att bara läsa dem, men jag tror att det finns något att säga för att ta något som många av oss antingen gör eller upplever och se hur detta kan förändras inom sammanhanget för WordPress.
Ta biverkningar från Basic Coding Standard (eller PSR-1 ), till exempel:
En fil SKA deklarera nya symboler (klasser, funktioner, konstanter, etc.) och inte orsaka några andra biverkningar, eller så SKA den köra logik med biverkningar, men SKA INTE göra båda.
Frasen "biverkningar" betyder exekvering av logik som inte är direkt relaterad till att deklarera klasser, funktioner, konstanter, etc., bara från att inkludera filen.
Personligen tycker jag att den andra frasen är nyckeln till att förstå och undvika biverkningar i vår kod så mycket som möjligt. Det vill säga, allt som våra klasser gör ska vara fristående eller vara sammanhängande med något som kan ha injicerats på något sätt.
Oavsett vilket borde det inte vara så svårt att hitta kod som introducerar en bieffekt och rensa upp den. Jag ska faktiskt använda mig själv som ett exempel.
Titta på denna speciella kodbit :
Den här koden kommer direkt från Toggle Admin Notices. Visst, det är enkelt, och förvaret visar en anteckning om hur man ändrar det. Det visar ändå poängen, eller hur?
Vad är lösningen? Detta kommer i form av Autoloading (som också täcks av PSR-4 ). Så tänk om jag skulle refaktorera den, så den följde PSR-1 ordentligt? Sedan kan ett sätt att omstrukturera det se ut så här :
Är detta ett bra exempel? Antagligen inte. Men det handlar om mer än att bara inkludera filer. Inklusive dessa filer är att få denna enda fil att introducera en mängd olika biverkningar.
Det betyder att bara den här filen är ansvarig för att göra mycket mer än bara de fyra raderna kod. Se det som att det innehåller allt som andra filer implementerar. Det blir mer komplext då.
Så ta den idén och flytta den till ett mycket större system så kan du se hur och varför detta skulle vara problematiskt.
Naturligtvis finns det alternativa sätt också. Och detta är bara ett exempel. Självföraktande också. Poängen handlar inte så mycket om att visa ett definitivt sätt att göra detta utan att börja skapa tankar för hur vi designar, planerar, bygger och integrerar klasser.
Vad sägs om vyer?
När det kommer till att skriva plugins, är jag partisk med att behandla vad användare kommer att se som vyer. Men det verkar finnas en hake här: Det anses vara en dålig praxis att inkludera filer eftersom det introducerar biverkningar.
Så vi vill inte mata ut logik i våra klasser, utan vi vill också skilja presentation från affärslogik.
Vad ska vi göra?
Tvisten … är att vi kommer att använda objektorienterad programmering för att göra det. Vi kommer att designa en klass som genererar HTML med hjälp av PHP-mall.
Detta har behandlats på djupet av någon annan, och jag rekommenderar starkt att du läser just det inlägget för att ta tanken på biverkningar, undvika dem och införliva fasta metoder så mycket som möjligt.
…Och tillgångar och relaterade filer?
Jag vet: Tanken på att gå bort från biverkningar (låt vara att identifiera dem) kan vara konstig i början, speciellt när du tänker på vissa saker vi har gjort så länge.
Och det kan väcka frågor som: Är det fel att inkludera JavaScript-filer eller CSS-filer? Det är nog ett ämne för ett annat inlägg. Kom dock ihåg att det finns kärn-API-funktioner som är direkt relaterade till det, och de kan vara en del av en klass som är strikt ansvarig för att göra det.
Om en klasss syfte är att göra exakt det och bara det och den använder API-funktioner för att göra det, så skulle jag säga att det troligen är okej.
Men jag avviker från det för nu (och kanske är det ett ämne för kommentarerna eller, återigen, ett annat inlägg).
Håll istället dina klasser smala och målmedvetna. De bör göra som PSR-1 säger och undvika att göra saker som att "[deklarera] nya klasser, funktioner, konstanter, etc." och "[utföra] logik med biverkningar."