7

Muchas veces encuentro código difícil de leer, ya que esta poco estructurado o sin indentar. En SOes podemos encontrar multiples ejemplos de esto.

Buscando en el sitio una pregunta que abordara este tema, di con esta de @A.Cedano, Convención de nombres en PHP, pero realmente no aborda el tema de estilo o buenas practicas. Tampoco encontre ninguna pregunta que aborde los PSR 1 y 2.

Si pude encontrar otra similar haciendo referencia a html, css y js. Guías de estilo oficiales para HTML, CSS y Javascript

Por ello lanzo esta pregunta:

¿Cúales son los tips o recomendaciones en cuanto al estilo y orden del código que se deberían de tener en cuenta cuando desarrollamos con PHP?

Xerif
  • 7,283
  • 3
  • 17
  • 41
  • Me leíste el pensamiento, cuando vi tu excelente respuesta en la otra pregunta pensé precisamente que aquella iba dirigida específicamente a la *convención de nombres*, no a las guías de estilo. – A. Cedano Nov 23 '17 at 23:37
  • 2
    Considero que la guía de estilo es una decisión que se debe tomar en cada proyecto con cada equipo. No obstante, los `PSR` son un buen punto de partida que se puede adoptar tal cual, o se puede modificar al gusto. Como aporte extra a la conversación, para estandarizar el estilo de nuestro código podemos usar soluciones como [Code Sniffer](https://github.com/squizlabs/PHP_CodeSniffer) que nos marcará y avisará cuando nuestro estilo no cumpla con la guía establecida. – Muriano Nov 24 '17 at 07:49
  • Esta pregunta parece un poco subjetiva y abierta a opiniones (el mismo párrafo final está pidiendo recomendaciones) y podría tener muchas respuestas diferentes. – Alvaro Montoro Nov 25 '17 at 12:23
  • @AlvaroMontoro Como en toda guía de estilo su normas son recomendaciones. Los mismo PSR son recomendaciones, los puedes tener en cuenta o no. Pero creo que es algo importante cuando el código va a ser expuesto a otras personas. Puse la pregunta así para no cerrarla unicamente a los PSR y hacer cabida a otras guias y recomendaciones de estilo que puedan existir. un saludo. – Xerif Nov 25 '17 at 14:02
  • @Xerif A eso es a lo que me refiero: cualquier guía o recomendación de estilo valdría como respuesta a esta pregunta, y (casi) todas serían igualmente válidas como respuestas. – Alvaro Montoro Nov 25 '17 at 16:06

2 Answers2

12

La mejor guía de estilo a la que nos podemos acoger a la hora de desarroyar un proyecto en PHP es al PHP Standards Recommendations (PSR). En concreto los PSR 1 y 2 que hacen referencia a codificación básica y al estilo de codificación respectivamente.

PSR-1 Basic coding standard

  • Utilizar solo los tag <?php ?> y/o <?= ?>, ningún otro tag de apertura/cierre (ejemplo <? ?>, <% %>, etc...).
  • Utilizar siempre codificación UTF-8 sin BOM para el código PHP.
  • Los archivos deben declarar clases, funciones, constantes, etc... o ejecutar la lógica (por ejemplo, generar resultados, cambiar configuraciones de .ini, etc.) pero no deberían hacer ambas cosas.
  • Los espacios de nombres y las clases deben seguir PSR-0 ó PSR-4.
  • Los nombres de clase se declaran en StudlyCaps.
  • Las constantes se declaran en mayúsculas con separadores de subrayado (MI_CONSTANTE).
  • Los nombres de los métodos se declaran en camelCase.

PSR-2 Coding style guide

  • Usar 4 espacios para la sangría, no utilizar tabulaciones.
  • Las líneas deben tener menos de 80 caracteres. Las líneas más largas deberían dividirse en múltiples líneas.
  • No debería haber más de una declaración por línea.
  • Las palabras clave o reservadas deben estar en minusculas.
  • null, true y false deben estar en minuscula.
  • Debe haber una línea en blanco después de la declaración del namespace.
  • Debe haber una línea en blanco después de las declaraciones use.
  • Las palabras clave extends e implements deben declararse en la misma línea que el nombre de la clase.
  • La apertura de llaves { en las clases y métodos debe ir en la siguiente línea, y la llave de cierre } debe pasar a la siguiente línea después del cuerpo.
  • La visibilidad (public, protected o private) debe declararse siempre en todas las propiedades y métodos.
  • Entre el nombre de las funciones y métodos y los paréntesis ( ) no debe haber espacios en blanco (ejemplo: miFuncion()).
  • En la lista de argumentos, no debe haber un espacio antes de cada coma si debe haber un espacio después de cada coma.
  • Los argumentos del método con valores predeterminados deben ir al final de la lista de argumentos.
  • La llave de apertura { para estructuras de control (ejemplo: if) deben seguir en la misma línea, y la llave de cierre } debe pasar a la siguiente línea después del cuerpo.

Ejemplos:

Namespace y use

<?php
namespace Vendor\Package;

use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

// code

Extends y Implements

class ClassName extends ParentClass implements \ArrayAccess, \Countable
{
    // constants, properties, methods
}

Propiedades

class ClassName
{
    public $foo = null;

    // methods
}

Métodos

public function fooBarBaz($arg1, &$arg2, $arg3 = [])
{
    // method body
}

Métodos con argumento en varias lineas

public function aVeryLongMethodName(
    ClassTypeHint $arg1,
    &$arg2,
    array $arg3 = []
) {
    // method body
}

abstract, final y static

<?php
namespace Vendor\Package;

abstract class ClassName
{
    protected static $foo;

    abstract protected function zim();

    final public static function bar()
    {
        // method body
    }
}

Llamadas a métodos y funciones

<?php
// llamada a función
bar($arg2, $arg3);

// llamada a método
$foo->bar($arg1);

// llamada a método estático con argumentos
Foo::bar($arg2, $arg3);

// llamada a método con argumentos multilinea
$foo->bar(
    $longArgument,
    $longerArgument,
    $muchLongerArgument
);

if, elseif y else

<?php

if ($expr1) {
    // if body
} elseif ($expr2) {
    // elseif body
} else {
    // else body;
}

switch, case

<?php
switch ($expr) {
    case 0:
        echo 'First case, with a break';
        break;
    case 1:
        echo 'Second case, which falls through';
        // no break
    case 2:
    case 3:
    case 4:
        echo 'Third case, return instead of break';
        return;
    default:
        echo 'Default case';
        break;
}

while y do while

<?php
do {
    // structure body;
} while ($expr);

for

<?php
for ($i = 0; $i < 10; $i++) {
    // for body
}

foreach

<?php
foreach ($iterable as $key => $value) {
    // foreach body
}

try y catch

<?php
try {
    // try body
} catch (FirstExceptionType $e) {
    // catch body
} catch (OtherExceptionType $e) {
    // catch body
}

Fuente: https://github.com/php-fig/fig-standards

Xerif
  • 7,283
  • 3
  • 17
  • 41
1

Complementando la respuesta de @Xerif, es oportuno mencionar que estos PSR son hoy propuestos, mantenidos e implementados por el PHP Framework Interoperability Group el cual tiene peso porque congrega a representantes de los frameworks y librerías más importantes del ecosistema PHP:

  • CakePHP
  • Composer
  • Drupal
  • Magento
  • Phalcon
  • phpBB
  • Slim
  • Symphony
  • Yii
  • Zend Framework

(El único grande que no está es Laravel, pero Taylor Otwell se salió del FIG porque no tenía tiempo de participar en los debates, votar ni proponer. Sin embargo parte de Laravel adopta algunos PSR)

En el fondo, aunque este grupo no decida los features que están en el núcleo del motor de PHP, sí pueden decidir cómo operar con ellos adoptando convenciones que permitan la interoperabilidad entre frameworks.

Por ejemplo, PHP no tiene una clase nativa que maneje inyección de dependencias. Un constructo como ese cada uno lo implementa como quiere. Sin embargo, gracias a la existencia del PHP-FIG, y a que se alcanzó un acuerdo entre sus miembros, sacaron el PSR-11, que especifica cómo debe comportarse un contenedor de dependencias. Hoy en día si instalas un framework que utiliza symfony/dependency-injection como inyector, eres libre de cambiarlo por php-di/php-di porque implementan la misma interfaz.

Lo mismo ocurre con el manejo de $request y $response en las rutas. Hoy la mayoría de los frameworks adhiere al PSR-7. Eso significa por ejemplo que si quieres cambiar el motor de tu aplicación de Silex a Slim puedes dejar tus rutas tal como están.

Aunque esto no tenga que ver puntualmente con el estilo, esos PSR son vitales para el ecosistema PHP y refuerzan la cohesión entre los distintos actores.

ffflabs
  • 21,223
  • 25
  • 48