PSR-Huh?

Si eres un ávido desarrollador de PHP, es muy probable que hayas encontrado la abreviatura, PSR, que significa "Recomendación sobre los estándares de PHP". Al momento de escribir este artículo, hay cuatro de ellos: PSR-0 a PSR-3. Echemos un vistazo a lo que son, y por qué debería importarte (y participar).


Una breve historia

PHP nunca ha tenido un estándar uniforme para escribir código. Aquellos que mantienen varias bases de código se comprometen a escribir sus propias convenciones de nomenclatura y pautas de estilo de codificación. Algunos de estos desarrolladores eligen heredar un estándar bien documentado, como PEAR o Zend Framework; sin embargo, otros optan por escribir estándares completamente desde cero.


El Grupo Marco de Interoperabilidad

No dude en abrir un nuevo tema en la lista de correo.

En la conferencia php | tek en 2009, las personas que representan diversos proyectos discutieron sus opciones para trabajar entre proyectos. Seguramente no es una sorpresa que el tema principal de la agenda sea mantener un conjunto de estándares entre las bases de código..

Hasta hace poco, se etiquetaban como el "Grupo de estándares de PHP", pero ahora, operan bajo el paraguas, Framework Interoperability Group (FIG). Como se sentían, los primeros no describían con precisión las intenciones del grupo. Aunque el nombre de este grupo se refiere explícitamente a los marcos, los desarrolladores que representan todo tipo de proyectos han sido aceptados como miembros votantes..

La FIG pretende alojar una sección transversal del ecosistema de PHP, no exclusivamente desarrolladores de marcos. Por ejemplo, los marcos de Symfony, Lithium y CakePHP tienen un representante como miembro con derecho a voto, pero lo mismo ocurre con PyroCMS, phpDocumentor e incluso Composer.

Los miembros votantes pueden comenzar o participar en los votos; sin embargo, cualquier otra persona (¡incluido usted!) Puede convertirse en miembro de la comunidad de PHP-FIG al suscribirse a la lista de correo de PHP-FIG..

Esta lista de correo es donde tienen lugar las discusiones, los votos, las sugerencias y los comentarios..

La meta

El objetivo de la FIG es crear un diálogo entre los representantes del proyecto, con el objetivo de encontrar formas de trabajar juntos (interoperabilidad). En el momento de escribir este artículo, ese diálogo ha generado cuatro Recomendaciones de estándares de PHP: PSR-0 a PSR-3.

Esas recomendaciones son gratuitas y pueden ser adoptadas por cualquier persona, aunque nadie está obligado a hacerlo. De hecho, los miembros votantes no están obligados a implementar ninguno de los PSR en los proyectos que representan!


PSR-0: Autoloader Standard

PSR-0 es un gran paso adelante para el código reutilizable.

Recuerda cómo solías especificar muchos exigir declaraciones para hacer referencia a todas las clases que necesita? Afortunadamente, este patrón cambió con la magia de PHP 5 __autoload () función. PHP 5.1.2 hizo la carga automática incluso mejor introduciendo spl_autoload (), lo que le permite registrar una cadena de funciones de carga automática con spl_autoload_register ().

No importa cuán buena sea la funcionalidad de carga automática, no define cómo implementarla con bases de código existentes. Por ejemplo, biblioteca X podría acercarse a la estructura de directorio y nombre de clase de manera diferente a biblioteca y, pero es posible que desee utilizar ambos!

Escribir un autocargador adecuado que sepa dónde buscar todos los nombres completamente calificados posibles, así como probar todas las extensiones de archivo (.class.php, inc.php, .php, etc.) se convertirá rápidamente en un desastre. Sin un estándar para definir cómo nombrar las clases y dónde colocarlas, la interoperabilidad del autocargador aún sería un sueño imposible..

Conoce a PSR-0. Una recomendación estándar que describe "los requisitos obligatorios que deben cumplirse para la interoperabilidad del autocargador".

PSR-0 es un gran paso adelante para el código reutilizable. Si un proyecto sigue el estándar PSR-0 y sus componentes están acoplados libremente, simplemente puede tomar esos componentes, colocarlos dentro de un directorio de "proveedores" y usar un autocargador compatible con PSR-0 para incluir esos componentes. O, mejor aún, deja que Composer haga eso por ti.!

Por ejemplo, esto es exactamente lo que hace Laravel con dos componentes de Symfony (Console y HttpFoundation).

La FIG tiene un ejemplo de implementación de una función de autocargador compatible con PSR-0 que se puede registrar para spl_autoload_register (), pero eres libre de usar cualquiera de las implementaciones más flexibles, como el Desbloqueador de clases Symfony o el Cargador automático del compositor..


PSR-1: Estándar de codificación básica

PSR-1 se enfoca en un estándar de codificación básico..

Hubo un largo período de baja actividad en la FIG después de la aceptación del PSR-0. De hecho, pasaron un buen año y medio antes de que se aprobaran los documentos PSR-1 y PSR-2.

PSR-1 se enfoca en un estándar de codificación básico. Se abstiene de ser demasiado detallado y se limita a un conjunto de reglas básicas para "garantizar un alto nivel de interoperabilidad técnica entre el código PHP compartido".

  • Solo usa el y etiquetas.
  • Utilice únicamente UTF-8 sin BOM para el código PHP.
  • Efectos secundarios separados (generar salida, acceder a una base de datos, etc.) y declaraciones.
  • Aplicar PSR-0.
  • Los nombres de clase deben estar definidos en StudlyCaps.
  • Las constantes de clase deben definirse en mayúsculas con separadores de subrayado.
  • Los nombres de los métodos se deben definir en camelCase.

Las reglas básicas se centran en las convenciones de nomenclatura y la estructura de archivos. Esto asegura que todo el código PHP compartido se comporte y se vea de la misma manera en un nivel alto. Imagine una aplicación que utiliza numerosos componentes de terceros, y todos ellos utilizan diferentes convenciones de nomenclatura y codificaciones de caracteres. Eso seria un desastre!


PSR-2: Guía de estilo de codificación

El propósito de PSR-2 es tener una única guía de estilo para el código PHP que dé como resultado un código compartido con formato uniforme.

PSR-2 extiende y expande los estándares básicos de codificación de PSR-1. Su propósito es tener una única guía de estilo para el código PHP que dé como resultado un código compartido con formato uniforme.

Las reglas de la guía de estilo de codificación se decidieron después de una amplia encuesta entre los miembros votantes de la FIG..

Las reglas en PSR-2, acordadas por los miembros votantes, no necesariamente reflejan las preferencias de todos los desarrolladores de PHP. Sin embargo, desde el comienzo de la FIG, PHP-FIG ha declarado que sus recomendaciones siempre han sido para la FIG; Otros dispuestos a adoptar las recomendaciones son un resultado positivo..

La especificación completa de PSR-2 se puede encontrar en el repositorio de los estándares de fig. Asegúrate de leerlo.

En un mundo ideal, cada proyecto de PHP adoptaría las recomendaciones que se encuentran en PSR-1 y PSR-2. Sin embargo, debido al gusto (es decir, "¡La convención de nombres x se ve mejor que y!", "¡Pestañas sobre espacios!") Y la segmentación histórica entre varios estilos de codificación, solo ha habido una cantidad escasa de proyectos PHP que adoptan PSR-1 y PSR- 2 en su totalidad.


PSR-3: Interfaz de registrador

PSR-3 describe una interfaz de registro compartida.

La Recomendación n. ° 3 de PHP es la adición más reciente a los estándares FIG aceptados. Fue aceptado el 27 de diciembre de 2012 con un impresionante conteo de votos de 18 a 0 (8 miembros votantes no emitieron un voto).

PSR-3 describe una interfaz de registro compartida, que incorpora los ocho niveles de Syslog del Protocolo Syslog (RFC 5424): depuración, información, aviso, advertencia, error, crítico, alerta y emergencia.

Esos ocho niveles de Syslog se definen como nombres de métodos, que aceptan dos parámetros: una cadena con un registro $ mensaje y un opcional $ contexto matriz con datos adicionales que no encajan bien en la cadena anterior. Los implementadores pueden entonces reemplazar los marcadores de posición en $ mensaje con valores de $ contexto.

Un estándar de interfaz compartida, como PSR-3, permite que los marcos, las bibliotecas y otras aplicaciones puedan escribir sugerencias en esa interfaz compartida, lo que permite a los desarrolladores elegir una implementación preferida.

En otras palabras: si se sabe que un componente de registro se adhiere al PSR-3, simplemente se puede intercambiar con un componente de registro diferente compatible con PSR-3. Esto asegura la máxima interoperabilidad entre las llamadas a las implementaciones del registrador.

Monolog implementó recientemente el PSR-3. Por lo tanto, es conocido por implementar la Psr \ Log \ LoggerInterface y sus directrices asociadas que se encuentran en el documento PSR-3.


Crítica

PHP-FIG está haciendo un gran trabajo al centralizar los estándares de PHP..

Algunas personas dicen que los PSR van demasiado lejos para definir un conjunto global de estándares para definir un estilo de codificación, algo que es más subjetivo que objetivo. Otros creen que una interfaz compartida es demasiado específica y no flexible. Pero la crítica viene naturalmente con cualquier iniciativa estándar. A la gente no le gusta cómo se deben nombrar los identificadores, qué sangría se usa, o cómo se forman los estándares.

La mayor parte de las críticas y reflexiones tienen lugar desde la línea lateral., después los estándares son aceptados, aunque los estándares se encuentran en la lista de correo (que está abierto para que todos puedan participar y dejar comentarios, comentarios o sugerencias). No dude en abrir un nuevo tema en la lista de correo, si cree que tiene algo valioso que agregar.

También es importante tener en cuenta que no es la combinación específica de reglas, lo que contribuye al beneficio de los estándares recomendados, sino que tiene un conjunto coherente de reglas que se comparten entre varios códigos de base..

Si todos evitan sus propias preferencias, tenemos un estilo coherente desde el exterior hacia adentro, lo que significa que puedo usar CUALQUIER paquete, no solo el que sea camelCase..

- Phil Sturgeon en la lista de correo PHP-FIG


El futuro

La FIG pretende alojar una sección transversal del ecosistema PHP, no solo los desarrolladores de marcos.

Con un número creciente de miembros con voto influyentes y cuatro estándares aceptados, el FIG ciertamente está ganando más tracción en la comunidad de PHP. PSR-0 ya tiene un uso generalizado, y es de esperar que PSR-1 y PSR-2 sigan su ejemplo para lograr una mayor uniformidad en el código PHP compartido.

Con la interfaz compartida definida en PSR-3, el Grupo de Interoperabilidad del Marco tomó un nuevo giro en la recomendación de estándares. Todavía se dirigen en esa dirección, ya que los contenidos de las nuevas interfaces compartidas se discuten en la lista de correo..

Actualmente hay una discusión interesante sobre la propuesta de un paquete de mensajes HTTP, que contiene interfaces compartidas para implementar un cliente HTTP. También hay varias discusiones que proponen una interfaz de caché compartida; Pero, a partir de ahora, parece estar en baja actividad..

No importa cuál sea el resultado de esas propuestas, PHP-FIG está haciendo un gran trabajo al centralizar los estándares de PHP. Sin lugar a dudas, influyen de manera positiva en la ecosfera de PHP, y esperamos que sus esfuerzos obtengan un lugar más prominente en el lenguaje de programación de PHP..

.