Cualquiera puede formular una pregunta

Stack Overflow en español es un sitio de

preguntas y respuestas para programadores y
profesionales de la informática. Solo te toma Cualquiera puede responder
un minuto registrarte.

Regístrate para unirte a esta comunidad Se vota a favor de las mejores

respuestas, y éstas suben a los
primeros puestos

Guia de estilo y buenas practicas PHP

Formulada hace 5 años y 2 meses Modificada hace 5 años y 2 meses Vista 4k veces

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.
7
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?

php

Compartir Mejora esta pregunta Seguir editada el 23 nov. 2017 a las 23:39 formulada el 23 nov. 2017 a las
23:34
Xerif
7,371 3 17 42

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 el 23 nov. 2017 a las 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 que nos marcará y avisará cuando nuestro estilo no cumpla con la guía
establecida. – Muriano el 24 nov. 2017 a las 7: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 ♦ el 25 nov. 2017 a las 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 el 25 nov. 2017 a las
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 ♦ el 25 nov. 2017 a las 16:06

2 respuestas Ordenado por: Mayor puntuación (por defecto)

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
12 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

Compartir Mejora esta respuesta Seguir editada el 25 nov. 2017 a las 10:56 respondida el 23 nov. 2017 a las
23:34
Xerif
7,371 3 17 42

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
1 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.

Compartir Mejora esta respuesta Seguir respondida el 24 nov. 2017 a las

11:28
ffflabs
22k 26 50