La trilogía del PSR. Capítulo 3

En el segundo post de esta trilogía te hablé acerca de las herramientas que podías usar para seguir a rajatabla el PSR. Nos centramos en cómo configurar VIM ya que es uno de mis editores favoritos, sino el que más. Bien, pues hoy te traigo la tercera y última entrega de esta trilogía en la que te comentaré las dos reglas más usadas y qué intenta solucionar para que puedas entender mejor su necesidad.

PSR-1

El PSR-1 es básicamente una pequeña guía de estilo de código. En ella se establecen unos requerimientos muy básicos de cómo debería ser el código como puede ser el uso de tags de PHP completos (<?php ?>), el requerimiento de que el código no contenga sentencias que puedan tener efectos colaterales, que viene a ser todo lo que no sea declaración de clases o implementación de funciones, es decir, cambios del ini en tiempo de ejecución, include de archivos, etc.

También dictamina que los espacios de nombres y las clases deben seguir el PSR-4 y que los nombres de clase deben estar escritos en StudlyCaps, por ejemplo, MiEspacioDeNombres/MiClase o que el nombre de las constantes deben estar en mayúscula.

Con esto se consigue que una librería pueda ser usada por cualquier proyecto que adopte el PSR, ya que se garantiza que se va a autocargar las clases de una misma manera.

PSR-2

El PSR-2 entra algo más de lleno en cómo se debe escribir el código, definiendo reglas para el posicionamiento de algunas palabras reservadas del lenguaje como static o abstract. También menciona la longitud deseada de una línea de código (80 columnas) o la ubicación de los parámetros en llamadas a métodos en los que tenemos que pasar muchos.

• Evidentemente, el código debe cumplir con el PSR-1.

• No se debe usar tabulaciones. En su lugar, se deben usar cuatro espacios para indentación. Esto hace que el código se vea homogéneo sin importar el editor que lo abra.

• No debe existir un límite obligatorio para la longitud de una línea. Aunque lo ideal es que midan ochenta columnas o menos y se considerará error de estilo sobrepasar las 120 columnas. Esto mejora la legibilidad del código al tener un menor recorrido que realizar en horizontal.

• Debe haber una línea en blanco después de la declaración del espacio de nombres y una línea después de todos los use. Esto separa de una manera lógica diferentes secciones de la cabecera de una clase.

• La apertura de llaves debe estar en la siguiente línea de la declaración de una clase y el cierre justo la línea después del cuerpo. Hacer esto da importancia a la declaración de la clase y hace que se leer sin confusión entre líneas.

• Ocurre exactamente lo mismo para las definiciones de métodos y funciones.

• La visibilidad de las declaraciones deben definirse en todos los atributos y métodos. Teniendo presente que las palabras abstract y final van antes de la visibilidad y static después. Con esto se consigue una mejor legibilidad al usar una sintaxis más cercana a la humana (en inglés, claro)

• Las estructuras de control deben tener un espacio después al contrario que las funciones que van pegadas a los paréntesis.

• La apertura de llaves para las estructuras de control van en la misma línea y la de cierre justo en la línea siguiente del cuerpo.

• El paréntesis de apertura de las estructuras de control no deben tener espacio después de él. Del mismo modo, el paréntesis de cierre no debe tener espacio antes de él.

CONCLUSIÓN

Como ves son unas reglas sencillitas. Tienes que tener en cuenta que el motivo detrás de estas reglas es que todo el mundo lea el código de la misma manera. Por eso algunas reglas pueden sonar desfasadas.

Una que siempre me dicen que no se entiende es la de las ochenta columnas; piensa que tienes que hacer un cambio en caliente y la única manera es accediendo físicamente al servidor… Probablemente no tengas entorno gráfico y, si es así, probablemente solo tendrás ochenta columnas para ver tu código.

Otro ejemplo es el de las tabulaciones. El problema de las tabulaciones es que se puede configurar cómo quieres que sean de anchas, lo que haría que no todo el mundo viera el código de la misma manera… Pues se soluciona indentando con espacio.

Las demás reglas del PSR proporcionan interfaces para implementar diferentes componentes como una clase de cache´ o un wrapper de los mensajes HTTP. Si quieres más información sobre estos PSR o extender con ejemplos los que te he explicado aquí, visita la web oficial de PHP Standars Recommendations.

¡Espero que te haya resultado útil! ¿Por qué no nos cuentas tu experiencia en los comentarios?

Foto: rules de Steve Johnson