Share
Se sei un appassionato sviluppatore PHP, è molto probabile che ti sia capitato di trovare la sigla, PSR, che sta per "PHP Standards Recommendation". Al momento della stesura di questo documento, ce ne sono quattro: PSR-0 su PSR-3. Diamo un'occhiata a cosa sono e perché dovresti curarti (e partecipare).
PHP non ha mai avuto uno standard uniforme per scrivere codice. Coloro che mantengono varie codebase si impegnano a scrivere le proprie convenzioni di denominazione e le linee guida sullo stile di codifica. Alcuni di questi sviluppatori scelgono di ereditare uno standard ben documentato, come PEAR o Zend Framework; altri ancora scelgono di scrivere standard completamente da zero.
Non esitate ad aprire un nuovo argomento nella mailing list.
Alla conferenza php | tek del 2009, le persone che rappresentavano vari progetti hanno discusso le loro opzioni per lavorare tra i progetti. Sicuramente non sorprende che attenersi a una serie di standard tra i codebase sia stato l'elemento principale dell'agenda.
Fino a poco tempo fa, si definivano "PHP Standards Group", ma ora operano sotto l'egida di Framework Interoperability Group (FIG). Come sentivano, il primo non descriveva accuratamente le intenzioni del gruppo. Anche se il nome di questo gruppo si riferisce esplicitamente a quadri, gli sviluppatori che rappresentano tutti i tipi di progetti sono stati accettati come membri votanti.
La FIG intende ospitare una sezione trasversale dell'ecosistema PHP, non esclusivamente gli sviluppatori di framework. Ad esempio, i framework Symfony, Lithium e CakePHP hanno ciascuno un rappresentante come membro votante, ma lo stesso vale per PyroCMS, phpDocumentor e persino Composer.
I membri votanti possono iniziare o partecipare ai voti, tuttavia, chiunque altro (incluso te!) Può diventare un membro della comunità PHP-FIG aderendo alla mailing list PHP-FIG.
Questa mailing list è dove si svolgono discussioni, voti, suggerimenti e feedback.
L'obiettivo della FIG è quello di creare un dialogo tra i rappresentanti del progetto, con l'obiettivo di trovare modi per lavorare insieme (interoperabilità). Al momento di questa stesura, quel dialogo ha generato quattro raccomandazioni per gli standard PHP: PSR-0 a PSR-3.
Queste raccomandazioni sono gratuite e possono essere adottate da chiunque, anche se nessuno è obbligato a farlo. In effetti, ai membri votanti non è richiesto di implementare alcuno dei PSR nei progetti che rappresentano!
PSR-0 è un enorme passo avanti per il codice riutilizzabile.
Ricorda come hai usato per specificare molti richiedere dichiarazioni per fare riferimento a tutte le classi che richiedete? Per fortuna, questo schema è cambiato con la magia di PHP 5 __autoload () funzione. PHP 5.1.2 ha reso l'autoloading ancora migliore introducendo spl_autoload (), che ti permette di registrare una catena di funzioni di autoloading con spl_autoload_register ().
Non importa quanto sia buona la funzionalità di autoloading, non definisce come implementarlo con basi di codice esistenti. Per esempio, libreria X potrebbe avvicinarsi alla directory e alla struttura del nome della classe diversamente da biblioteca Y, ma potresti voler usare entrambi!
Scrivere un autoloader appropriato che sappia dove cercare tutti i nomi possibili e completi, oltre a testare tutte le estensioni di file (.class.php, inc.php, .php ecc.) Diventerà presto un casino. Senza uno standard per definire come denominare le classi e dove collocarle, l'interoperabilità del caricatore automatico sarebbe ancora un sogno irrealizzabile.
Ti presentiamo PSR-0. Una raccomandazione standard che descrive "i requisiti obbligatori che devono essere rispettati per l'interoperabilità del caricatore automatico".
PSR-0 è un enorme passo avanti per il codice riutilizzabile. Se un progetto segue lo standard PSR-0 e i suoi componenti sono accoppiati liberamente, è sufficiente prendere quei componenti, inserirli in una directory "vendor" e utilizzare un autoloader compatibile con PSR-0 per includere tali componenti. O, ancora meglio, lascia che sia Compositore a farlo per te!
Ad esempio, questo è esattamente ciò che fa Laravel con due componenti Symfony (Console e HttpFoundation).
La FIG ha un'implementazione di esempio di una funzione di autoloader compatibile con PSR-0 che può essere registrata su spl_autoload_register (), ma sei libero di utilizzare qualsiasi implementazione più flessibile, come il disaccoppiatore Symfony ClassLoader o il caricatore automatico del compositore.
PSR-1 si concentra su uno standard di codifica di base.
C'è stato un lungo periodo di bassa attività nella FIG dopo l'accettazione di PSR-0. In realtà, ci sono voluti un buon anno e mezzo prima che i documenti PSR-1 e PSR-2 fossero approvati.
PSR-1 si concentra su uno standard di codifica di base. Si astiene dall'essere troppo dettagliato e lo fa limitandosi a un insieme di regole fondamentali per "garantire un alto livello di interoperabilità tecnica tra il codice PHP condiviso".
Accentsconagua
e tag.Le regole di base si concentrano sulle convenzioni di denominazione e sulla struttura dei file. Ciò garantisce che tutto il codice PHP condiviso si comporti e abbia lo stesso aspetto a un livello elevato. Immagina un'applicazione che utilizza numerosi componenti di terze parti e tutti usano convenzioni di denominazione e codifiche di caratteri diverse. Quello sarebbe un casino!
Lo scopo di PSR-2 è quello di avere un'unica guida di stile per il codice PHP che si traduce in un codice condiviso uniformemente formattato.
PSR-2 estende e amplia gli standard di codifica di base della PSR-1. Il suo scopo è quello di avere un'unica guida di stile per il codice PHP che si traduce in un codice condiviso uniformemente formattato.
Le regole della guida di stile di codifica sono state decise dopo un ampio sondaggio dato ai membri votanti della FIG.
Le regole in PSR-2, concordate dai membri votanti, non riflettono necessariamente le preferenze di ogni sviluppatore PHP. Dall'inizio della FIG, tuttavia, la PHP-FIG ha dichiarato che le loro raccomandazioni sono sempre state per la FIG stessa; altri disposti ad adottare le raccomandazioni sono un risultato positivo.
La specifica completa PSR-2 può essere trovata nel repository fig-standards. Assicurati di dargli una lettura.
In un mondo ideale, ogni progetto PHP adotterebbe le raccomandazioni trovate in PSR-1 e PSR-2. Tuttavia, a causa del gusto (vale a dire "convenzione di denominazione x sembra migliore di y!", "Tabulazioni sugli spazi!") E segmentazione storica tra vari stili di codifica, c'è stata solo una quantità scarsa di progetti PHP che adottano PSR-1 e PSR- 2 nella sua interezza.
La PSR-3 descrive un'interfaccia di logging condivisa.
La Raccomandazione N.3 di PHP è l'aggiunta più recente agli standard accettati della FIG. È stato accettato il 27 dicembre 2012 con un impressionante voto di 18 a 0 (8 membri votanti non hanno espresso un voto).
La PSR-3 descrive un'interfaccia di logging condivisa, che incorpora gli otto livelli Syslog di The Syslog Protocol (RFC 5424): debug, informazioni, avviso, avviso, errore, critico, avviso e emergenza.
Questi otto livelli Syslog sono definiti come nomi di metodi, che accettano due parametri: una stringa con un log $ messaggio e un opzionale $ contesto array con dati aggiuntivi che non si adattano bene alla stringa precedente. Gli implementatori possono quindi sostituire i segnaposto in $ messaggio con valori da $ contesto.
Uno standard di interfaccia condiviso, come PSR-3, consente a framework, librerie e altre applicazioni di digitare suggerimenti su quell'interfaccia condivisa, consentendo agli sviluppatori di scegliere un'implementazione preferita.
In altre parole: se è noto che un componente di registrazione aderisce alla PSR-3, può semplicemente essere scambiato con un componente di registrazione conforme alla PSR-3 differente. Questo assicura la massima interoperabilità tra le chiamate alle implementazioni del logger.
Monolog ha recentemente implementato PSR-3. È quindi noto implementare il Psr \ Log \ LoggerInterface e le relative linee guida associate trovate nel documento PSR-3.
PHP-FIG sta facendo un ottimo lavoro di centralizzazione degli standard PHP.
Alcuni dicono che i PSR vanno troppo oltre per definire un insieme globale di standard per definire uno stile di codifica - qualcosa che è più soggettivo che obiettivo. Altri ritengono che un'interfaccia condivisa sia troppo specifica e non flessibile. Ma le critiche vengono naturalmente con qualsiasi iniziativa standard. Le persone non amano il modo in cui gli identificatori dovrebbero essere nominati, quale indentazione viene utilizzata o come vengono formati gli standard.
La maggior parte delle critiche e delle riflessioni si svolgono dalla linea laterale, dopo gli standard sono accettati, anche se gli standard si formano nella mailing list (che è aperta a tutti per partecipare e lasciare feedback, commenti o suggerimenti). Non esitare ad aprire un nuovo argomento nella mailing list, se pensi di avere qualcosa di prezioso da aggiungere.
È anche importante ricordare che non è la combinazione specifica di regole, che contribuisce al beneficio degli standard raccomandati, ma piuttosto un insieme coerente di regole che sono condivise tra varie codebase.
Se tutti ignorano le proprie preferenze, abbiamo uno stile coerente dall'esterno, il che significa che posso utilizzare QUALSIASI pacchetto, non solo quello che capita di essere camelCase.
- Phil Sturgeon nella mailing list di PHP-FIG
La FIG intende ospitare una sezione trasversale dell'ecosistema PHP, non solo gli sviluppatori di framework.
Con un numero crescente di membri votanti influenti e quattro standard accettati, la FIG sta sicuramente guadagnando più aderenza nella comunità di PHP. PSR-0 ha già un uso diffuso, e si spera che PSR-1 e PSR-2 seguiranno l'esempio per ottenere più uniformità nel codice PHP condiviso.
Con l'interfaccia condivisa definita in PSR-3, il Framework Interoperability Group ha preso una nuova svolta nella raccomandazione degli standard. Stanno ancora andando in quella direzione, poiché i contenuti di nuove interfacce condivise sono stati discussi sulla mailing list.
Attualmente c'è un'interessante discussione sulla proposta di un pacchetto di messaggi HTTP, che contiene interfacce condivise per l'implementazione di un client HTTP. Ci sono anche varie discussioni che propongono un'interfaccia Cache condivisa; ma, a partire da ora, sembra essere in bassa attività.
Indipendentemente dall'esito di tali proposte, PHP-FIG sta facendo un ottimo lavoro di centralizzazione degli standard PHP. Senza dubbio influenzano l'ecosfera di PHP in modo positivo, e si spera che i loro sforzi otterranno un posto più prominente nel linguaggio di programmazione PHP.
.
