Share
Dacă sunteți un dezvoltator avid PHP, este foarte probabil că ați întâlnit abrevierea, PSR, care reprezintă "Recomandarea privind standardele PHP". La momentul acestei scrieri, sunt patru: PSR-0 la PSR-3. Să aruncăm o privire la ce sunt acestea și de ce ar trebui să aveți grijă (și să participați).
PHP nu a avut niciodată un adevărat standard pentru scrierea codului. Cei care întrețin diverse baze de coduri se angajează să scrie propriile convenții de numire și orientările stilului de codare. Unii dintre acești dezvoltatori aleg să moștenească un standard bine documentat, cum ar fi PEAR sau Zend Framework; dar alții aleg să scrie standarde complet de la zero.
Nu ezitați să deschideți un nou subiect în lista de discuții.
La conferința php | tek din 2009, reprezentanții diferitelor proiecte au discutat opțiunile lor de a lucra între proiecte. Cu siguranță, nu este o surpriză faptul că menținerea unui set de standarde între baze de coduri a reprezentat principalul element de pe ordinea de zi.
Până de curând ei se etichetau drept "Grupul de standarde PHP", dar acum funcționează sub grupul-cadru "Interoperability Framework" (FIG). După cum au simțit, prima nu descrie cu exactitate intențiile grupului. Chiar dacă numele acestui grup se referă explicit la cadre, dezvoltatorii care reprezintă tot felul de proiecte au fost acceptați ca membri cu drept de vot.
FIG intenționează să găzduiască o secțiune transversală a ecosistemului PHP, nu numai dezvoltatorii de cadre. De exemplu, cadrele Symfony, Lithium și CakePHP au fiecare câte un reprezentant ca membru cu drepturi de vot, dar același lucru este valabil și pentru PyroCMS, phpDocumentor și chiar pentru Composer.
Membrii cu drept de vot pot începe sau participa la vot, totuși oricine altcineva (inclusiv dumneavoastră!) Poate deveni membru al comunității PHP-FIG prin abonarea la lista de discuții PHP-FIG.
Această listă de discuții este locul în care au loc discuții, voturi, sugestii și feedback.
Scopul FIG este de a crea un dialog între reprezentanții proiectului, cu scopul de a găsi modalități de colaborare (interoperabilitate). La momentul acestei scrieri, dialogul a generat patru recomandări de standarde PHP: PSR-0 la PSR-3.
Aceste recomandări sunt gratuite și pot fi adoptate de oricine, deși nimeni nu este obligat să facă acest lucru. De fapt, membrii cu drept de vot nu sunt obligați să pună în aplicare niciuna dintre PSR-urile în proiectele pe care le reprezintă!
PSR-0 este un pas imens pentru codul reutilizabil.
Amintiți-vă cum ați specificat multe necesita declarații de referință pentru toate clasele pe care le solicitați? Din fericire, acest model sa schimbat cu magia PHP 5 __autoload () funcţie. PHP 5.1.2 a făcut autoloading chiar mai bine prin introducerea spl_autoload (), care vă permite să înregistrați un lanț de funcții autoloading cu spl_autoload_register ().
Indiferent de cât de bun este funcționalitatea autoloading, ea nu definește modul de implementare a acesteia cu codurile existente. De exemplu, biblioteca X ar putea aborda structura directorului și a clasei în mod diferit decât biblioteca Y, dar este posibil să doriți să utilizați ambele!
Scrierea unui autoloader adecvat, care știe unde să caute toate numele posibile pe deplin calificate, precum și testarea tuturor extensiilor de fișiere (.class.php, inc.php, .php etc.) va deveni rapid o mizerie. Fără un standard care să definească cum să numească clasele și unde să le plaseze, interoperabilitatea autoloader ar fi încă un vis de conducte.
Faceți cunoștință cu PSR-0. O recomandare standard care descrie "cerințele obligatorii care trebuie respectate pentru interoperabilitatea autoloader".
PSR-0 este un pas imens pentru codul reutilizabil. Dacă un proiect respectă standardul PSR-0 și componentele acestuia sunt cuplate în mod liber, puteți să le luați pur și simplu, să le plasați într-un director "vânzător" și să utilizați un autoloader compatibil PSR-0 pentru a include aceste componente. Sau, chiar mai bine, lăsați-l pe compozitor să facă asta!
De exemplu, acesta este exact ceea ce face Laravel cu două Symfony Components (Console și HttpFoundation).
FIG prezintă un exemplu de implementare a unei funcții autoloader compatibile PSR-0 la care se poate înregistra spl_autoload_register (), dar sunteți liber să utilizați oricare dintre implementările mai flexibile, cum ar fi deconectat Symfony ClassLoader sau autoloader Composer.
PSR-1 se concentrează pe un standard de codificare de bază.
A fost o perioadă lungă de activitate scăzută în FIG după acceptarea lui PSR-0. De fapt, a durat un an și jumătate înainte ca documentele PSR-1 și PSR-2 să fie aprobate.
PSR-1 se concentrează pe un standard de codificare de bază. Acesta se abține de la a fi prea detaliat și face acest lucru prin limitarea la un set de reguli de bază pentru a "asigura un nivel ridicat de interoperabilitate tehnică între codul partajat PHP".
Accentsconagua
și Etichete.Regulile de bază se concentrează asupra convențiilor de denumire și a structurii fișierelor. Acest lucru asigură faptul că toate codurile PHP partajate se comportă și arată în același mod la un nivel ridicat. Imaginați-vă o aplicație care utilizează numeroase componente ale unor terțe părți și toate utilizează convenții de numire diferite și codificări de caractere. Ar fi o mizerie!
Obiectivul PSR-2 este acela de a avea un singur ghid de stil pentru codul PHP care să aibă ca rezultat un cod partajat formatat uniform.
PSR-2 extinde și extinde standardele de bază de codare PSR-1. Scopul său este de a avea un singur ghid de stil pentru codul PHP care să aibă ca rezultat un cod partajat formatat uniform.
Regulile ghidului de stil de codare au fost decise după un sondaj amplu acordat membrilor care votează FIG.
Regulile din PSR-2, convenite de membrii care votează, nu reflectă neapărat preferințele fiecărui dezvoltator PHP. Încă de la începutul figurii, PHP-FIG a declarat că recomandările lor au fost întotdeauna pentru FIG în sine; altele care doresc să adopte recomandările sunt un rezultat pozitiv.
Specificația completă PSR-2 poate fi găsită în depozitul de standarde de figuri. Asigurați-vă că ați citit-o.
Într-o lume ideală, fiecare proiect PHP va adopta recomandările din PSR-1 și PSR-2. Cu toate acestea, din cauza gustului (adică "convenția de naming x arată mai bine decât y!", "Tabs over spaces!") Și segmentarea istorică între diferite stiluri de codificare, au existat doar puține proiecte PHP care adoptă PSR-1 și PSR- 2 în întregime.
PSR-3 descrie o interfață de conectare partajată.
Recomandarea standard din PHP nr. 3 este cea mai recentă completare a standardelor acceptate de FIG. A fost acceptat pe 27 decembrie 2012 cu un număr impresionant de voturi de la 18 la 0 (8 membri care au votat nu au votat).
PSR-3 descrie o interfață de conectare partajată, care încorporează cele opt niveluri Syslog ale Protocolului Syslog (RFC 5424): depanare, informații, notificare, avertizare, eroare, critică, alertă și de urgență.
Cele opt niveluri Syslog sunt definite ca nume de metode, care acceptă doi parametri: un șir cu un jurnal $ mesaj și opțional $ context array cu date suplimentare care nu se potrivesc bine în fostul șir. Aplicații pot înlocui apoi substituenții în $ mesaj cu valori de la $ context.
Un standard de interfață comună, cum ar fi PSR-3, are ca rezultat cadre, biblioteci și alte aplicații care pot tipa sugestii pe acea interfață comună, permițând dezvoltatorilor să aleagă o implementare preferată.
Cu alte cuvinte: dacă o componentă de logare este cunoscută pentru a adera la PSR-3, ea poate fi schimbată pur și simplu cu o altă componentă de logare compatibilă cu PSR-3. Aceasta asigură o interoperabilitate maximă între apelurile către implementările loggerului.
Monolog a implementat recent PSR-3. Este, prin urmare, cunoscut să pună în aplicare Psr \ Log \ LoggerInterface și orientările sale asociate găsite în documentul PSR-3.
PHP-FIG face o treabă excelentă de centralizare a standardelor PHP.
Unii oameni spun că PSR-urile merg prea departe pentru a defini un set global de standarde pentru a defini un stil de codificare - ceva mai subiectiv decât obiectiv. Alții consideră că o interfață comună este prea specifică și nu este flexibilă. Dar critica vine în mod natural cu orice inițiativă standard. Oamenilor nu le place cum ar trebui să fie numiți identificatori, care indentare este folosită sau cum se formează standardele.
Cea mai mare parte a criticii și a reflecției are loc din partea laterală, după standardele sunt acceptate - chiar dacă standardele se formează în lista de corespondență (care este deschisă tuturor pentru a se înscrie și a lăsa feedback, comentarii sau sugestii). Nu ezitați să deschideți un nou subiect în lista de discuții, dacă credeți că aveți ceva important de adăugat.
De asemenea, este important să rețineți că nu este o combinație specifică de reguli care contribuie la folosirea standardelor recomandate, ci mai degrabă un set consistent de reguli care sunt împărțite între diferitele baze de coduri.
Deoarece fiecare își retrage propriile preferințe, avem un stil consistent din exterior - în sensul că pot folosi orice pachet - nu doar ceea ce se întâmplă să fie camelCase.
- Phil Sturgeon în lista de discuții PHP-FIG
FIG intenționează să găzduiască o secțiune transversală a ecosistemului PHP, nu numai dezvoltatorii de cadre.
Cu un număr tot mai mare de membri cu drepturi de vot și patru standarde acceptate, FIG cu siguranță câștigă mai multă tracțiune în comunitatea PHP. PSR-0 are deja o utilizare pe scară largă și sperăm că PSR-1 și PSR-2 vor urma exemplul pentru a obține o mai mare uniformitate în codul PHP partajat.
Cu interfața comună definită în PSR-3, Grupul de Interoperabilitate Cadru a luat o nouă tendință în recomandarea standardelor. Acestea continuă să se îndrepte în această direcție, deoarece conținutul noilor interfețe comune este discutat pe lista de discuții.
În prezent există o discuție interesantă despre propunerea unui pachet de mesaje HTTP, care conține interfețe partajate pentru implementarea unui client HTTP. Există, de asemenea, diverse discuții care propun o interfață de cache partajată; dar, de acum, se pare că are o activitate redusă.
Indiferent de rezultatul acestor propuneri, PHP-FIG face o treabă excelentă de centralizare a standardelor PHP. Acestea influențează fără îndoială ecosistemul PHP în mod pozitiv și sperăm că eforturile lor vor obține un loc mai proeminent în limba de programare PHP.
.
