Share
Als je een fervent PHP-ontwikkelaar bent, is de kans groot dat je de afkorting bent tegengekomen, PSR, wat staat voor "PHP Standards Recommendation." Op het moment van dit schrijven zijn er vier: PSR-0 tot PSR-3. Laten we eens kijken naar wat deze zijn, en waarom je zou moeten geven (en deelnemen).
PHP heeft nooit echt een uniforme standaard gehad voor het schrijven van code. Degenen die verschillende codebases onderhouden, besteden tijd aan het schrijven van hun eigen naamgevingsconventies en richtlijnen voor codeerstijlen. Sommige van deze ontwikkelaars kiezen ervoor om een goed gedocumenteerde standaard te erven, zoals PEAR of Zend Framework; weer anderen kiezen ervoor om normen volledig vanaf nul te schrijven.
Aarzel niet om een nieuw onderwerp in de mailinglijst te openen.
Op de php | tek-conferentie in 2009 bespraken mensen die verschillende projecten vertegenwoordigden hun opties voor het werken tussen projecten. Het is zeker geen verrassing dat het vasthouden aan een reeks normen tussen codebases het belangrijkste agendapunt was.
Tot voor kort noemden ze zichzelf als de 'PHP-standaardengroep', maar nu opereren ze onder de paraplu, Framework Interoperability Group (FIG). Zoals ze voelden, beschreef de eerste de intenties van de groep niet nauwkeurig. Hoewel de naam van deze groep expliciet naar kaders verwijst, zijn ontwikkelaars die allerlei projecten vertegenwoordigen geaccepteerd als stemgerechtigde leden.
De FIG is van plan een dwarsdoorsnede van het PHP-ecosysteem te hosten, niet alleen kaderontwikkelaars. De Symfony-, Lithium- en CakePHP-raamwerken hebben bijvoorbeeld elk een vertegenwoordiger als stemhebbend lid, maar hetzelfde geldt voor PyroCMS, phpDocumentor en zelfs Composer.
De stemgerechtigde leden kunnen stemmen starten of eraan deelnemen, maar iedereen (inclusief u!) Kan lid worden van de PHP-FIG-community door zich te abonneren op de PHP-FIG-mailinglijst.
Op deze mailinglijst vinden discussies, stemmen, suggesties en feedback plaats.
Het doel van de FIG is om een dialoog tot stand te brengen tussen projectvertegenwoordigers, met als doel manieren te vinden om samen te werken (interoperabiliteit). Op het moment van schrijven heeft deze dialoog geleid tot vier aanbevelingen voor PHP-standaarden: PSR-0 tot PSR-3.
Die aanbevelingen zijn gratis en kunnen door iedereen worden aangenomen, hoewel niemand hiertoe verplicht is. Stemleden zijn zelfs niet verplicht om een van de PSR's te implementeren in de projecten die zij vertegenwoordigen!
PSR-0 is een enorme stap vooruit voor herbruikbare code.
Onthoud hoe je veel hebt gespecificeerd vereisen verklaringen om te verwijzen naar alle klassen die u nodig heeft? Gelukkig veranderde dit patroon met de magie van PHP 5 __autoload () functie. PHP 5.1.2 maakte autoloading nog beter door te introduceren spl_autoload (), waarmee u een keten van autoloadfuncties kunt registreren met spl_autoload_register ().
Ongeacht hoe goed de autoloading-functionaliteit is, deze definieert niet hoe deze moet worden geïmplementeerd met bestaande codebases. Bijvoorbeeld, bibliotheek X kan de directory en classname-structuur anders benaderen dan bibliotheek Y, maar misschien wilt u beide gebruiken!
Het schrijven van een juiste autoloader die weet waar te zoeken naar alle mogelijke volledig gekwalificeerde namen, evenals het testen van alle bestandsextensies (.class.php, inc.php, .php enz.) Zal snel een puinhoop worden. Zonder een standaard om te definiëren hoe klassen te benoemen en waar ze te plaatsen, zou interoperabiliteit van de autoloader nog steeds een droom zijn.
Maak kennis met PSR-0. Een standaardaanbeveling die beschrijft "de verplichte vereisten waaraan moet worden voldaan voor interoperabiliteit van de autoloader."
PSR-0 is een enorme stap vooruit voor herbruikbare code. Als een project de PSR-0-standaard volgt en de componenten ervan losjes gekoppeld zijn, kunt u eenvoudig die componenten nemen, ze in een 'leveranciers'-map plaatsen en een PSR-0-compatibele autoloader gebruiken om die componenten op te nemen. Of, nog beter, laat Composer dat voor u doen!
Dit is bijvoorbeeld precies wat Laravel doet met twee Symfony-componenten (Console en HttpFoundation).
De FIG heeft een voorbeeldimplementatie van een PSR-0-compatibele autoloaderfunctie waarop kan worden geregistreerd spl_autoload_register (), maar je bent vrij om een van de meer flexibele implementaties te gebruiken, zoals de ontkoppelde Symfony ClassLoader of de autoloader van Composer.
PSR-1 richt zich op een standaard coderingsstandaard.
Er was een lange periode van lage activiteit in de FIG na acceptatie door de PSR-0. In feite duurde het anderhalf jaar voordat de PSR-1- en PSR-2-documenten werden goedgekeurd.
PSR-1 richt zich op een standaard coderingsstandaard. Het onthoudt zich van te gedetailleerd te zijn, en doet dit door zich te beperken tot een aantal basisregels om "een hoog niveau van technische interoperabiliteit tussen gedeelde PHP-code te waarborgen".
Accentsconagua
en labels.De basisregels zijn gericht op naamgevingsconventies en bestandsstructuur. Dit zorgt ervoor dat alle gedeelde PHP-code zich gedraagt en op dezelfde manier op een hoog niveau lijkt. Stel u een toepassing voor die gebruikmaakt van een groot aantal externe componenten en die allemaal verschillende naamconventies en tekencoderingen gebruiken. Dat zou een zooitje zijn!
Het doel van PSR-2 is om één stijlgids voor PHP-code te hebben die resulteert in uniform geformatteerde gedeelde code.
PSR-2 breidt uit en breidt de standaard coderingsstandaarden van PSR-1 uit. Het doel is om een enkele stijlgids voor PHP-code te hebben die resulteert in uniform opgemaakte gedeelde code.
De regels voor de coderingsstijlgids zijn vastgesteld na een uitgebreide enquête aan de FIG-stemmende leden.
De regels in PSR-2, goedgekeurd door de stemmende leden, komen niet noodzakelijk overeen met de voorkeuren van elke PHP-ontwikkelaar. Sinds het begin van de FIG. Heeft de PHP-FIG echter verklaard dat hun aanbevelingen altijd voor de FIG zelf zijn geweest; anderen die bereid zijn de aanbevelingen over te nemen, zijn een positief resultaat.
De volledige PSR-2-specificatie is te vinden in de fig-standards repository. Zorg ervoor dat je het leest.
In een ideale wereld zou elk PHP-project de aanbevelingen uit PSR-1 en PSR-2 overnemen. Echter, vanwege smaak (bijv. "Naamcongres x ziet er beter uit dan y!", "Tabs over spaties!") En historische segmentatie tussen verschillende codeerstijlen, zijn er maar een schaars aantal PHP-projecten geweest met PSR-1 en PSR- 2 in zijn geheel.
PSR-3 beschrijft een gedeelde logboekinterface.
PHP Standaard Aanbeveling # 3 is de meest recente toevoeging aan de geaccepteerde FIG-normen. Het werd op 27 december 2012 aanvaard met een indrukwekkend aantal stemmen van 18 tot 0 (8 stemgerechtigde leden hebben geen stem uitgebracht).
PSR-3 beschrijft een gedeelde logging-interface, waarin de acht Syslog-niveaus van The Syslog Protocol (RFC 5424) zijn opgenomen: debug, info, notice, warning, error, critical, alert en emergency.
Die acht Syslog-niveaus worden gedefinieerd als methodamen, die twee parameters accepteren: een string met een log $ message en een optioneel $ context array met extra gegevens die niet goed in de vorige tekenreeks passen. Uitvoerders kunnen dan plaatshouders vervangen in $ message met waarden van $ context.
Een gedeelde interfacestandaard, zoals PSR-3, heeft tot gevolg dat kaders, bibliotheken en andere applicaties een hint kunnen typen op die gedeelde interface, waardoor ontwikkelaars een voorkeursimplementatie kunnen kiezen.
Met andere woorden: als bekend is dat een logboekcomponent aan PSR-3 voldoet, kan deze eenvoudig worden verwisseld met een andere PSR-3-compatibele logboekcomponent. Dit zorgt voor maximale interoperabiliteit tussen oproepen naar logger-implementaties.
Monolog heeft onlangs PSR-3 geïmplementeerd. Het is daarom bekend om het te implementeren Psr \ Log \ LoggerInterface en de bijbehorende richtlijnen in het PSR-3-document.
De PHP-FIG doet geweldig werk van het centraliseren van PHP-standaarden.
Sommige mensen zeggen dat de PSR's te ver gaan om een algemene reeks normen te definiëren om een coderingsstijl te definiëren - iets dat subjectiever is dan objectief. Anderen menen dat een gedeelde interface te specifiek en niet flexibel is. Maar kritiek komt vanzelf met elk standaardinitiatief. Mensen houden er niet van hoe identifiers worden genoemd, welke inspringing wordt gebruikt of hoe de standaarden worden gevormd.
De meeste kritiek en reflectie vinden vanaf de zijlijn plaats, na de standaarden worden geaccepteerd - ook al vormen de normen in de mailinglijst (die voor iedereen open staat om deel te nemen en feedback, opmerkingen of suggesties achter te laten). Aarzel niet om een nieuw onderwerp in de mailinglijst te openen, als je denkt dat je iets waardevols toe te voegen hebt.
Het is ook belangrijk om in gedachten te houden dat het niet de specifieke combinatie van regels is die bijdraagt aan het voordeel van de aanbevolen standaarden, maar veeleer één consistente set regels heeft die worden gedeeld tussen verschillende codebases..
Door iedereen zijn eigen voorkeuren te laten schuiven, hebben we één consistente stijl van buiten naar binnen, wat betekent dat ik ELK pakket kan gebruiken - niet alleen wat er ook gebeurt met camelCase.
- Phil Sturgeon in de PHP-FIG-mailinglijst
De FIG is van plan een dwarsdoorsnede van het PHP-ecosysteem te hosten, niet alleen framework-ontwikkelaars.
Met een groeiend aantal invloedrijke stemmende leden en vier geaccepteerde normen, wint de FIG zeker meer grip in de PHP-gemeenschap. PSR-0 heeft al een wijdverbreid gebruik, en hopelijk volgen PSR-1 en PSR-2 hetzelfde voor meer uniformiteit in gedeelde PHP-code.
Met de gedeelde interface gedefinieerd in PSR-3, nam de Framework Interoperability Group een nieuwe wending in het aanbevelen van standaarden. Ze gaan nog steeds in die richting, omdat de inhoud van nieuwe gedeelde interfaces wordt besproken op de mailinglijst.
Momenteel is er een interessante discussie over het voorstel van een HTTP-berichtenpakket, dat gedeelde interfaces bevat voor het implementeren van een HTTP-client. Er zijn ook verschillende discussies die een gedeelde Cache-interface voorstellen; maar vanaf nu lijkt het om een lage activiteit.
Ongeacht wat de uitkomst van die voorstellen zal zijn, de PHP-FIG doet geweldig werk van het centraliseren van PHP-standaarden. Ze beïnvloeden zonder twijfel de PHP-ecosfeer op een positieve manier en hopelijk zullen hun inspanningen een prominentere plaats krijgen in de PHP-programmeertaal.
.
