Share
Om du är en ivrig PHP-utvecklare är det ganska sannolikt att du har stött på förkortningen, PSR, vilket står för "PHP Standards Recommendation." Vid det här skrivandet finns fyra av dem: PSR-0 till PSR-3. Låt oss ta en titt på vad dessa är och varför du bör bry dig om (och delta).
PHP har aldrig riktigt haft en enhetlig standard för att skriva kod. De som behåller olika kodbaser förbinder sig att skriva sina egna namngivningskonventioner och kodningsstilriktlinjer. Några av dessa utvecklare väljer att ärva en väl dokumenterad standard, såsom PEAR eller Zend Framework; men andra väljer att skriva standarder helt från början.
Tveka inte att öppna ett nytt ämne i postlistan.
Vid php | tek konferensen 2009 diskuterade personer som representerar olika projekt sina möjligheter att arbeta mellan projekt. Det kommer säkert inte som någon överraskning att det var det viktigaste agendapunktet att hålla sig till en uppsättning standarder mellan kodbaser.
Fram till nyligen betecknade de sig som "PHP Standards Group", men nu arbetar de under paraplyet Framework Interoperability Group (FIG). Som de ansåg, beskriver inte den förstnämnda gruppen noggrant gruppens avsikter. Även om namnet på denna grupp uttryckligen hänvisar till ramar, har utvecklare som representerar alla möjliga projekt godkänts som röstande medlemmar.
FIG avser att vara värd för ett tvärsnitt av PHP-ekosystemet, inte enbart ramutvecklare. Symfony-, Lithium- och CakePHP-ramarna har till exempel en representant som en röstmedlem, men detsamma gäller PyroCMS, phpDocumentor och till och med Kompositör.
Röstmedlemmarna kan börja eller delta i röster, men någon annan (inklusive dig!) Kan bli en PHP-FIG-gruppmedlem genom att prenumerera på PHP-FIG-postlistan.
Denna postlista är där diskussioner, röster, förslag och feedback äger rum.
Syftet med FIG är att skapa en dialog mellan projektrepresentanter, med målet att hitta sätt att arbeta tillsammans (driftskompatibilitet). Vid denna skrivning har denna dialog skapat fyra rekommendationer om PHP-standarder: PSR-0 till PSR-3.
Dessa rekommendationer är gratis och kan antas av någon, men ingen är skyldig att göra det. Faktum är att röster är inte skyldiga att genomföra någon av PSR i de projekt som de representerar!
PSR-0 är ett stort steg framåt för återanvändbar kod.
Kom ihåg hur du brukade ange många fordra uttalanden för att referera till alla de klasser du behöver? Tack och lov ändras det här mönstret med PHP 5: s magi __autoload () fungera. PHP 5.1.2 gjorde autoloading ännu bättre genom att införa spl_autoload (), vilket gör att du kan registrera en kedja av autoloadingfunktioner med spl_autoload_register ().
Oavsett hur bra autoloadingfunktionen är, definierar den inte hur man implementerar den med befintliga kodbaser. Till exempel, bibliotek X kan närma sig katalogen och klassnamnstrukturen annorlunda än bibliotek Y, men du kanske vill använda båda!
Att skriva en riktig autoloader som vet var man ska leta efter alla möjliga fullt kvalificerade namn, samt testa alla filtillägg (.class.php, inc.php, .php etc) blir snabbt en röra. Utan en standard för att definiera hur man namnger klasser och var de ska placeras, skulle autoloaderinteroperabilitet fortfarande vara en rördröm.
Möt PSR-0. En standard rekommendation som beskriver "de obligatoriska kraven som måste följas för autoloader interoperabilitet."
PSR-0 är ett stort steg framåt för återanvändbar kod. Om ett projekt följer PSR-0-standarden och dess komponenter är löst kopplade, kan du helt enkelt ta dessa komponenter, placera dem i en "leverantörskatalog" och använda en PSR-0-kompatibel autoloader för att inkludera dessa komponenter. Eller, ännu bättre, låt Composer göra det för dig!
Det här är exakt vad Laravel gör med två Symfony-komponenter (Console och HttpFoundation).
FIG har ett exempel implementering av en PSR-0-kompatibel autoloader-funktion som kan registreras till spl_autoload_register (), men du är fri att använda något av de mer flexibla implementationerna, till exempel den frikopplade Symfony ClassLoader eller Composer's autoloader.
PSR-1 fokuserar på en grundläggande kodningsstandard.
Det var en lång period med låg aktivitet i figuren efter PSR-0: s acceptans. Faktum är att det tog ett gott år innan PSR-1 och PSR-2-dokumenten godkändes.
PSR-1 fokuserar på en grundläggande kodningsstandard. Den avstår från att vara för detaljerad och gör det genom att begränsa sig till en uppsättning grundregler för att "säkerställa en hög teknisk kompatibilitet mellan delad PHP-kod".
Accentsconagua
och taggar.Grundreglerna fokuserar på namngivna konventioner och filstruktur. Detta säkerställer att all delad PHP-kod beter sig och ser på samma sätt på en hög nivå. Tänk dig en applikation som använder många komponenter från tredje part, och de använder alla olika namnkonventioner och teckenkodningar. Det skulle vara en röra!
PSR-2s syfte är att ha en enda stilguide för PHP-kod som resulterar i enhetligt formaterad delad kod.
PSR-2 utökar och expanderar PSR-1s grundläggande kodningsstandarder. Dess syfte är att ha en enda stilguide för PHP-kod som resulterar i enhetligt formaterad delad kod.
Kodningsguideens regler bestämdes efter en omfattande undersökning som gavs till de röstberättigade medlemmarna.
Reglerna i PSR-2, som överenskommits av de röstande medlemmarna, speglar inte nödvändigtvis preferensen för varje PHP-utvecklare. Sedan figurens början har emellertid PHP-FIG angett att deras rekommendationer alltid har varit för FIG själv; Andra som är villiga att anta rekommendationerna är ett positivt resultat.
Den fullständiga PSR-2-specifikationen finns i figstandarddatabasen. Var noga med att ge den en läsning.
I en ideal värld skulle varje PHP-projekt anta rekommendationerna i PSR-1 och PSR-2. På grund av smaken (det vill säga "Naming convention x ser bättre ut än y!", "Flikar över mellanslag!") Och historisk segmentering mellan olika kodningsstilar har det bara varit en sparsam mängd PHP-projekt som antar PSR-1 och PSR- 2 i sin helhet.
PSR-3 beskriver ett delat logggränssnitt.
PHP Standard Recommendation # 3 är det senaste tillägget till de accepterade FIG-standarderna. Den godkändes den 27 december 2012 med ett imponerande röstetal på 18 till 0 (8 röstdeltagare röstade inte).
PSR-3 beskriver ett delat logggränssnitt som innehåller de åtta syslognivåerna i Syslog-protokollet (RFC 5424): felsökning, information, varning, varning, fel, kritisk, varning och nödsituation.
De åtta syslognivåerna definieras som metodnamn, vilka accepterar två parametrar: en sträng med en logg $ message och en valfri $ sammanhang array med ytterligare data som inte passar bra i den tidigare strängen. Implementörer kan då ersätta platsägare i $ message med värden från $ sammanhang.
En gemensam gränssnittsstandard, som PSR-3, resulterar i ramar, bibliotek och andra applikationer som kan skriva tips om det delade gränssnittet, så att utvecklare kan välja ett föredraget genomförande.
Med andra ord: om en loggkomponent är känd för att ansluta sig till PSR-3, kan den helt enkelt bytas ut med en annan PSR-3-kompatibel loggkomponent. Detta garanterar maximal driftskompatibilitet mellan samtal till logger implementeringar.
Monolog genomförde nyligen PSR-3. Det är därför känt att genomföra Psr \ Log \ LoggerInterface och dess associerade riktlinjer som finns i PSR-3-dokumentet.
PHP-FIG gör ett bra jobb med att centralisera PHP-standarder.
Vissa säger att PSR: erna går för långt för att definiera en global uppsättning standarder för att definiera en kodningsstil - något som är mer subjektivt än objektivt. Andra anser att ett delat gränssnitt är för specifikt och inte flexibelt. Men kritik kommer naturligt med något standardinitiativ. Människor gillar inte hur identifierare ska namnges, vilken indragning som används, eller hur standarderna bildas.
Huvuddelen av kritiken och reflektionen sker från sidlinjen, efter Standarderna accepteras - även om standardformuläret i postlistan (som är öppet för alla att gå med och lämna feedback, kommentarer eller förslag). Tveka inte att öppna ett nytt ämne i postlistan, om du tycker att du har något värdefullt att lägga till.
Det är också viktigt att komma ihåg att det inte är den specifika kombinationen av regler som bidrar till de rekommenderade standarderna utan att ha en konsekvent uppsättning regler som delas mellan olika kodbaser.
Av alla shirking sina egna preferenser har vi en konsekvent stil från utsidan, vilket innebär att jag kan använda något paket - inte bara det som råkar vara kamelCase.
- Phil Sturgeon i PHP-FIG-postlistan
FIG avser att vara värd för ett tvärsnitt av PHP-ekosystemet, inte bara ramutvecklare.
Med ett växande antal inflytelserika röstmedlemmar och fyra accepterade standarder, är FIG visserligen mer dragkraft i PHP-samhället. PSR-0 har redan en omfattande användning, och förhoppningsvis kommer PSR-1 och PSR-2 att följa efter för att uppnå mer enhetlighet i delad PHP-kod.
Med det delade gränssnittet definierat i PSR-3 tog Framework Interoperability Group en ny tur i att rekommendera standarder. De är fortfarande på väg i den riktningen, eftersom innehållet i nya delade gränssnitt diskuteras på postlistan.
För närvarande finns en intressant diskussion om förslaget till ett HTTP-meddelandepaket, som innehåller delade gränssnitt för att implementera en HTTP-klient. Det finns också olika diskussioner som föreslår ett gemensamt Cache-gränssnitt. men från och med nu verkar det vara låg aktivitet.
Oavsett vad resultatet av dessa förslag kommer att vara, gör PHP-FIG ett bra jobb med att centralisera PHP-standarder. De påverkar utan tvekan PHP-ekosfären på ett positivt sätt, och förhoppningsvis kommer deras ansträngningar att få en mer framträdande plats i PHP-programmeringsspråket.
.
