PSR-2 – guía de estilo de codificación en PHP 7

PSR-2 es una extensión de PSR-1. Esto significa que cuando se habla de PSR-2, el estándar PSR-1 se entiende implícitamente. La diferencia es que PSR-2 se expande más allá del formato básico de clase y función enumerando un conjunto de reglas sobre cómo formatear el código PHP.
Las reglas de estilo descritas se derivan de similitudes compartidas entre los diversos proyectos miembros de PFP-FIG.


El código DEBE seguir una guía de estilo de codificación PSR (PSR-1). Se dice que cada código PSR-2 es implícitamente compatible con PSR-1.
El código DEBE usar 4 espacios para sangría, no pestañas. El dilema de espacios versus pestañas es bastante antiguo en el mundo de la programación. Hay quienes votaron por el grupo PHP-FIG por el uso de espacios, mientras que 4 espacios representan lo que generalmente es una sangría de tabulación única. El beneficio de un espacio sobre una pestaña es coherencia. Mientras que una pestaña podría aparecer como un número diferente de columnas dependiendo del entorno, un solo espacio siempre es una columna. Si bien este podría no ser el argumento más convincente de todos, los estándares continúan diciendo que 4 espacios constituyen un solo guión. Piense en ello como 4 espacios para lo que una vez fue una sola sangría. La mayoría de los editores IDE modernos de hoy en día, como PhpStorm, manejan esto automáticamente por nosotros.

NO DEBE haber un límite estricto en la longitud de la línea; el límite flexible DEBE ser de 120 caracteres; las líneas DEBEN tener 80 caracteres o menos. El argumento de longitud de línea de 80 caracteres es tan antiguo como la programación misma. La tarjeta perforada IBM, diseñada en 1928, tenía las 80 columnas con 12 perforaciones cada una, un caracter para cada columna. Esta elección de diseño de 80 caracteres por fila se pasó luego a terminales basados ​​en caracteres. Aunque los avances del dispositivo de visualización están mucho más allá de estas limitaciones, incluso hoy en día, algunos mensajes de comando permanecen establecido en 80 columnas. Este estándar básicamente dice que si bien podríamos usar cualquier longitud que queramos, es altamente preferible mantenerla por debajo de 80 caracteres.
DEBE haber una línea en blanco después de la declaración del espacio de nombres, y DEBE haber una línea en blanco después de las declaraciones de bloque de uso. Aunque este no es un requisito técnico impuesto por el lenguaje en sí, el estándar lo exige. El requisito en sí es más de naturaleza cosmética. El uso resultante afecta la legibilidad del código para mejor.
Las siguientes líneas de código demuestran un ejemplo para evitar:

<?php
namespace Foggyline\User\Model;
use Foggyline\User\Model\Director;
class Employee
{
}

Las siguientes líneas de código demuestran un ejemplo a seguir:

<?php
namespace Foggyline\User\Model;
use Foggyline\User\Model\Director;
class Employee
{
}

Las llaves de apertura para las clases DEBEN ir en la línea siguiente, y las llaves de cierre DEBEN ir en la línea siguiente después del cuerpo. Del mismo modo, este no es un requisito técnico del lenguaje, sino cosmético.
Las siguientes líneas de código demuestran un ejemplo para evitar:

<?php
class Employee {
// cuerpo
}

Las siguientes líneas de código demuestran un ejemplo a seguir:

<?php
class Employee
{
// cuerpo
}

Las llaves de apertura para los métodos DEBEN ir en la línea siguiente, y las llaves de cierre DEBEN ir en la línea siguiente después del cuerpo. Nuevamente, este es un tipo de requisito cosmético, no es realmente impuesto por el lenguaje en sí.
Las siguientes líneas de código demuestran un ejemplo para evitar:

<?php
class Employee {
public function pay() {
// cuerpo
}
}

Las siguientes líneas de código demuestran un ejemplo a seguir:

<?php
class Employee
{
public function pay()
{
// cuerpo
}
}

La visibilidad DEBE declararse en todas las propiedades y métodos; abstract y final DEBEN declararse antes de la visibilidad; static DEBE declararse después de la visibilidad. La visibilidad es simplemente una abreviatura de lo que oficialmente se llama modificadores de acceso. Los métodos de clase en PHP pueden usar más de un modificador de acceso. El orden de los modificadores de acceso en tales casos no es relevante; podemos decir fácilmente abstract public function y public abstract function o final public function y public final function. Lo mismo ocurre cuando agregamos el modificador de acceso estático, donde efectivamente podríamos tener tres modificadores de acceso diferentes en un solo método. Este estándar especifica claramente que los modificadores abstractos y finales, si se usan, deben establecerse primero, mientras que los modificadores estáticos, si se usan, deben seguir los modificadores públicos y privados.

El siguiente bloque de código muestra un ejemplo para evitar:

<?php
abstract class User
{
public function func1()
{
// cuerpo
}
private function func2()
{
// cuerpo
}
protected function func3()
{
// cuerpo
}
public static abstract function func4();
static public final function func5()
{
// cuerpo
}
}
class Employee extends User
{
public function func4()
{
// cuerpo
}
}

El siguiente bloque de código muestra un ejemplo a seguir:

<?php
abstract class User
{
public function func1()
{
// cuerpo
}
private function func2()
{
// cuerpo
}
protected function func3()
{
// cuerpo
}
abstract public static function func4();
final public static function func5()
{
// cuerpo
}
}
class Employee extends User
{
public static function func4()
{
// cuerpo
}
}

Las palabras clave de la estructura de control DEBEN tener un espacio después de ellas; las llamadas a métodos y funciones NO. Este es un requisito bastante cosmético, que simplemente afecta la legibilidad del código.
Las siguientes líneas de código demuestran un ejemplo para evitar:

<?php
class Logger
{
public function log($msg, $code)
{
if($code >= 500) {
// lógica
}
}
}

Las siguientes líneas de código demuestran un ejemplo a seguir:

<?php
class Logger
{
public function log($msg, $code)
{
if ($code >= 500)
{
}
}
}

Las llaves de apertura para las estructuras de control DEBEN ir en la misma línea, y las llaves de cierre DEBEN ir en la línea siguiente después del cuerpo.
El siguiente bloque de código muestra un ejemplo para evitar:

<?php
class Logger
{
public function log($msg, $code)
{
if ($code === 500)
{
// lógica
}
elseif ($code === 600)
{
// lógica
}
elseif ($code === 700)
{
// lógica
}
else
{
// lógica
}
}
}

El siguiente bloque de código muestra un ejemplo a seguir:

<?php
class Logger
{
public function log($msg, $code)
{
if ($code === 500) {
// lógica
} elseif ($code === 600) {
// lógica
} elseif ($code === 700) {
// lógica
} else {
// lógica
}
}
}

Los paréntesis de apertura para estructuras de control NO DEBEN tener un espacio después de ellos, y los paréntesis de cierre para estructuras de control NO DEBEN tener un espacio delante de ellos. El espacio de paréntesis de cierre puede ser un poco confuso de entender aquí, porque, anteriormente, vimos el estándar impone espacios para sangría en lugar de pestañas. Esto significa que tendremos espacios antes de cerrar los corchetes. Sin embargo, solo debería haber suficiente espacio para representar la sangría real en el punto del corchete de cierre, nada más.
El siguiente ejemplo muestra un ejemplo para evitar (observe el espacio en la línea 7, después de la llave de apertura):

La siguiente imagen demuestra un ejemplo a seguir:


Comparte