Share
Hvis du er en ivrig PHP-utvikler, er det ganske sannsynlig at du har kommet over forkortelsen, PSR, som står for "PHP Standards Recommendation." På dette tidspunktet er det fire av dem: PSR-0 til PSR-3. La oss ta en titt på hva disse er, og hvorfor du bør bry deg om (og delta).
PHP har aldri hatt en enhetlig standard for å skrive kode. De som opprettholder ulike kodebaser, forplikter seg til å skrive sine egne navngivningskonvensjoner og kodestilretningslinjer. Noen av disse utviklerne velger å arve en godt dokumentert standard, for eksempel PEAR eller Zend Framework; men andre velger å skrive standarder helt fra grunnen av.
Ikke nøl med å åpne et nytt emne i postlisten.
På php | tek konferansen i 2009 diskuterte personer som representerte ulike prosjekter deres muligheter for å jobbe mellom prosjekter. Det kommer helt sikkert ikke som en overraskelse at det å holde seg til et sett med standarder mellom kodebaser var det viktigste dagsordenen.
Inntil nylig merket de seg som "PHP Standards Group", men nå opererer de under paraplyen Framework Interoperability Group (FIG). Som de følte, beskrev førstnevnte ikke nøyaktig gruppens intensjoner. Selv om navnet på denne gruppen eksplisitt refererer til rammer, har utviklere som representerer alle slags prosjekter blitt akseptert som stemmeberettigede medlemmer.
FIG har til hensikt å være vert for et tverrsnitt av PHP-økosystemet, ikke utelukkende rammeutviklere. For eksempel har Symfony-, Lithium- og CakePHP-rammene hver en representant som stemmedlem, men det samme gjelder PyroCMS, phpDocumentor, og til og med komponist.
De stemmeberettigede medlemmene kan starte eller delta i stemmer, men alle andre (inkludert deg!) Kan bli et PHP-FIG-medlem ved å abonnere på PHP-FIG-postlisten.
Denne postliste er hvor diskusjoner, stemmer, forslag og tilbakemelding finner sted.
Målet med FIG er å skape en dialog mellom prosjektrepresentanter, med sikte på å finne måter å jobbe sammen (interoperabilitet). På tidspunktet for denne skrivingen har denne dialogen skapt fire anbefalinger for PHP-standarder: PSR-0 til PSR-3.
Disse anbefalingene er gratis og kan adopteres av noen, men ingen er forpliktet til å gjøre det. Faktisk er ikke stemmeberettigede pålagt å implementere noen av PSRene i prosjektene de representerer!
PSR-0 er et stort skritt fremover for gjenbrukbar kode.
Husk hvordan du pleide å spesifisere mange krever uttalelser for å referere til alle klassene du trenger? Heldigvis endret dette mønsteret med PHP 5s magi __autoload () funksjon. PHP 5.1.2 gjorde autoloading enda bedre ved å introdusere spl_autoload (), som lar deg registrere en kjede av autoloading funksjoner med spl_autoload_register ().
Uansett hvor god autoloading funksjonaliteten er, definerer den ikke hvordan man implementerer den med eksisterende kodebaser. For eksempel, bibliotek X kan nærme seg katalogen og klassenavnstrukturen annerledes enn bibliotek Y, men du vil kanskje bruke begge!
Skrive en skikkelig autoloader som vet hvor du skal lete etter alle mulige fullt kvalifiserte navn, samt teste alle filtypene (.class.php, inc.php, .php etc), blir raskt et rot. Uten en standard for å definere hvordan å navngi klasser og hvor de skal plasseres, vil autoloaderinteroperabilitet fortsatt være en rørdrøm.
Møt PSR-0. En standard anbefaling som beskriver "de obligatoriske kravene som må overholdes for autoloader interoperabilitet."
PSR-0 er et stort skritt fremover for gjenbrukbar kode. Hvis et prosjekt følger PSR-0-standarden og komponentene er løst koblet, kan du enkelt ta de komponentene, plassere dem i en "leverandørkatalog" og bruke en PSR-0-kompatibel autolader for å inkludere disse komponentene. Eller, enda bedre, la Composer gjøre det for deg!
For eksempel, dette er akkurat hva Laravel gjør med to Symfony-komponenter (Console og HttpFoundation).
Fig. Har et eksempel på implementering av en PSR-0-kompatibel autoladerfunksjon som kan registreres til spl_autoload_register (), men du er fri til å bruke noen av de mer fleksible implementasjonene, for eksempel den avkoblede Symfony ClassLoader eller Composer's autoloader.
PSR-1 fokuserer på en grunnleggende kodingsstandard.
Det var en lang periode med lav aktivitet i figuren etter PSR-0s aksept. Faktisk tok det et godt og et halvt år før PSR-1 og PSR-2-dokumentene ble godkjent.
PSR-1 fokuserer på en grunnleggende kodingsstandard. Den avstår fra å være for detaljert, og gjør det ved å begrense seg til et sett med grunnregler for å "sikre et høyt nivå av teknisk interoperabilitet mellom delt PHP-kode".
Accentsconagua
og tags.Bakgrunnsreglene fokuserer på navnekonvensjoner og filstruktur. Dette sikrer at all delt PHP-kode oppfører seg og ser på samme måte på et høyt nivå. Tenk deg et program som bruker mange tredjepartskomponenter, og de bruker alle forskjellige navnekonvensjoner og tegnkodinger. Det ville være et rot!
PSR-2 har som mål å ha en enkelt stilguide for PHP-kode som resulterer i jevnt formatert delt kode.
PSR-2 utvider og utvider PSR-1s grunnleggende kodingsstandarder. Hensikten er å ha en enkelt stilguide for PHP-kode som resulterer i jevnt formatert delt kode.
Kodestilsguidenes regler ble avgjort etter en omfattende undersøkelse gitt til FIG-stemmeorganene.
Reglene i PSR-2, avtalt av stemmeberettigede medlemmer, gjenspeiler ikke nødvendigvis preferansen til hver PHP-utvikler. Siden figurens begynnelse har PHP-FIG imidlertid uttalt at deres anbefalinger alltid har vært for FIG selv; Andre som er villige til å vedta anbefalingene, er et positivt resultat.
Den fulle PSR-2 spesifikasjonen finnes i fig-standard depotet. Pass på å gi den en lesning.
I en ideell verden vil hvert PHP-prosjekt vedta anbefalingene som finnes i PSR-1 og PSR-2. På grunn av smaken (dvs. "Naming convention x ser bedre ut enn y!", "Tabs over spaces!") Og historisk segmentering mellom ulike kodestiler, har det bare vært en sparsom mengde PHP-prosjekter som vedtar PSR-1 og PSR- 2 i sin helhet.
PSR-3 beskriver et delt logggrensesnitt.
PHP Standard Recommendation # 3 er det nyeste tillegget til de aksepterte FIG-standardene. Det ble akseptert 27. desember 2012 med et imponerende antall stemmer på 18 til 0 (8 stemmer ikke stemte).
PSR-3 beskriver et delt logggrensesnitt, som inneholder de åtte Syslog-nivåene i The Syslog-protokollen (RFC 5424): feilsøking, informasjon, varsel, advarsel, feil, kritisk, varsel og nødsituasjon.
Disse åtte Syslog nivåene er definert som metodenavn, som aksepterer to parametere: en streng med en logg $ melding og en valgfri $ sammenheng array med flere data som ikke passer godt i den tidligere strengen. Implementere kan da erstatte plassholdere i $ melding med verdier fra $ sammenheng.
En felles grensesnittstandard, som PSR-3, resulterer i rammer, biblioteker og andre programmer som kan skrive hint på det delte grensesnittet, slik at utviklere kan velge en foretrukket implementering.
Med andre ord: Hvis en loggkomponent er kjent for å overholde PSR-3, kan den enkelt byttes med en annen PSR-3-kompatibel loggkomponent. Dette sikrer maksimal interoperabilitet mellom samtaler til logger implementeringer.
Monolog nylig implementert PSR-3. Det er derfor kjent å implementere PSR \ Log \ LoggerInterface og tilhørende retningslinjer som finnes i PSR-3-dokumentet.
PHP-FIG gjør en god jobb med sentralisering av PHP-standarder.
Noen sier at PSRene går for langt for å definere et globalt sett med standarder for å definere en kodestil - noe som er mer subjektivt enn objektivt. Andre føler at et delt grensesnitt er for spesifikt og ikke fleksibelt. Men kritikk kommer naturlig med et standardinitiativ. Folk liker ikke hvordan identifikatorer skal navngis, hvilket inntrykk som brukes, eller hvordan standardene dannes.
Mesteparten av kritikken og refleksjonen foregår fra sidelinjen, etter Standarden er akseptert - selv om standardskjemaet i adresselisten (som er åpent for alle å bli med og gi tilbakemelding, kommentarer eller forslag). Ikke nøl med å åpne et nytt emne i postlisten, hvis du tror du har noe verdifullt å legge til.
Det er også viktig å huske på at det ikke er den spesifikke kombinasjonen av regler, noe som bidrar til fordelene med de anbefalte standardene, men i stedet har et konsekvent sett av regler som deles mellom ulike kodebaser.
Av alle shirking sine egne preferanser har vi en konsistent stil fra utsiden, noe som betyr at jeg kan bruke en hvilken som helst pakke - ikke bare det som skjer for å være kamel.
- Phil Sturgeon i PHP-FIG mailinglisten
FIG har til hensikt å være vert for et tverrsnitt av PHP-økosystemet, ikke bare rammevilkårene.
Med et økende antall innflytelsesrike stemmedlemmer og fire aksepterte standarder, er FIG absolutt å få mer trekkraft i PHP-fellesskapet. PSR-0 har allerede utbredt bruk, og forhåpentligvis vil PSR-1 og PSR-2 følge etter for å oppnå mer enhetlighet i delt PHP-kode.
Med det delte grensesnittet definert i PSR-3, tok rammeinteroperabilitetsgruppen en ny tur i å anbefale standarder. De er fortsatt på vei i den retningen, da innholdet i nye delte grensesnitt blir diskutert på adresselisten.
For tiden er det en interessant diskusjon om forslaget til en HTTP Message Package, som har felles grensesnitt for implementering av en HTTP-klient. Det er også ulike diskusjoner som foreslår et felles Cache-grensesnitt; men fra nå av synes det å være på lav aktivitet.
Uansett hva utfallet av disse forslagene vil være, gjør PHP-FIG en god jobb med sentralisering av PHP-standarder. De er uten tvil påvirket PHP-økosfæren på en positiv måte, og forhåpentligvis vil deres innsats få et mer fremtredende sted i PHP-programmeringsspråket.
.
