Använda PSR:erna (versus WordPress-kodningsstandarderna)
Vid det här laget vet jag inte hur många artiklar jag har skrivit om vikten av WordPress Coding Standards (tillräckligt för att länka till dem här, här, och här, antar jag, vilket räknas för något).
Men efter att ha gjort tillräckligt många projekt för kunder och arbetat med utvecklare som är mycket smartare och bekanta med avancerade verktyg än jag, är jag på en plats där jag väljer att börja använda PSRs i WordPress WordPress-utveckling.
Åh dramat, eller hur?
Men allvarligt. Det finns anledningar till detta, och det finns tillfällen då jag tycker att WordPress-kodningsstandarderna fortfarande bör användas, men jag blir snabbt mer övertygad om att man bygger ett modernt projekt ovanpå WordPress bör använda mer moderna PHP-verktyg (vilket jag ska kort nämna senare).
Använda PSR i WordPress-utveckling
Inlägg som detta ger ofta insikter om någon debatt eller dramatisk respons inom WordPress, vilket inte är min avsikt och inte heller något som jag tror är nödvändigt. För att vara ärlig så känner jag en hel del andra utvecklare som alla har gjort detta för länge sedan, pratat om det, gått framåt och fortsatt att ha framgång både i sin verksamhet och i sina hobbyprojekt.
Men med tanke på att jag har pratat om den ena mot den andra så mycket, tänkte jag att det var värt att dela med mig av min syn på varför jag väljer att göra detta skifte nu och logiken bakom det.
1 Paritet med PHP-gemenskapen
Under det senaste året eller så, och egentligen bara under de senaste månaderna av detta år, har jag blivit mer van vid:
- mer erfarna PHP-orienterade utvecklarvänner som stöder verktyg som förväntar sig att PSR:erna kommer att antas,
- användningen av //@codingStandardsIgnoreStart och //@codingStandardsIgnoreEnd i min kod,
- anpassade regeluppsättningar för mina projekt baserat på de miljöer som de ligger bakom distribuerade,
- och mer.
I slutändan handlar det om att vilja bibehålla paritet (eller lite av det) med den större PHP-gemenskapen i stort och samtidigt skriva läsbar, standardbaserad kod ovanpå WordPress. Och jag skulle också vilja använda några andra verktyg och nyare versioner av befintliga verktyg (som jag kommer att diskutera senare i det här inlägget).
2 problem med moderna miljöer
När detta inlägg skrivs är PHP CodeSniffer (som krävs för att köra WordPress Coding Standards) version 3.0.2. Det finns dock kompatibilitetsproblem med PHPCS och med WordPress-kodningsstandarderna. Specifikt :
Den nya versionen av PHP CodeSniffer har några trevliga funktioner, men introducerar brytande förändringar som gör att WordPress-kodningsstandarderna inte är kompatibla.
För att vara tydlig (och på grund av programvarans natur) är det en tidsfråga innan det är åtgärdat. Men om du arbetar på en kodbas och du använder Composer och WordPress-kodningsstandarderna, måste du uttryckligen ställa in PHP CodeSniffer-versionen snarare än vad den senaste versionen för närvarande är.
Dessutom har jag upplevt problem med klienter där jag inte anammat PSR:erna i WordPress-utveckling har resulterat i konstigt beteende vid implementering av kod. Kanske skulle man kunna argumentera för att de borde anpassa miljön, men om de arbetar för att ha de modernaste verktygen tillgängliga för de människor som använder dem, varför gå tillbaka?
3 Kompatibilitet med moderna verktyg
Slutligen finns det ett antal moderna verktyg som jag inte har kunnat använda, än mindre inte kunnat lära mig, på grund av vad som är och vad som inte stöds av versionshanteringens natur.
Till exempel använde vi GrumPHP i ett nyligen genomfört projekt som har stöd för en mängd olika verktyg men vi kunde inte använda, säg, PHPMD på grund av bristande antagande av PSR. När det gäller mig:
- Jag vill ständigt höja mina färdigheter som utvecklare (och, i detta sammanhang, PHP-utvecklare),
- brist på stöd för modernare verktyg sätter mig i ett hållmönster som jag annars inte skulle uppleva,
- Jag vill fortsätta jobba med WordPress men gör det med ett modernare arbetsflöde
Och just nu skapar inte användningen av PSR en klyfta mellan vad resten av PHP-gemenskapen gör och vad WordPress gör. Så jag skulle vilja gå framåt samtidigt som jag fortsätter att arbeta med projekt utöver programvara som jag fortfarande tycker om att använda.
Vad sägs om WordPress-kodningsstandarderna
Så vad betyder detta om WordPress-kodningsstandarderna och tidigare inlägg? Ingenting egentligen. Som jag ser det: WordPress-kodningsstandarderna bör användas när du arbetar med WordPress Core eller något som kommer att vara nära integrerat i den.
Men om du arbetar med något som sitter ovanpå WordPress eller något som använder WordPress som grund och du kan använda PSR:erna i WordPress-utveckling tillsammans med verktyg som kan hjälpa till att öka kvaliteten på kodbasen som du bygger.
Så, åtminstone för nu, är det perspektivet jag kommer att anta. Jag är angelägen om att se hur det ser ut under de närmaste månaderna. Och när det gäller allt annat jag har delat, kommer jag att dela med mig av aspekterna av att göra det här bytet.