Los convenios son buenos. Ayudan a resolver siempre de una misma forma situaciones similares. Cada programador/proyecto tiene sus propios convenios de programación. En este artículo voy a contar los mios cuando desarrollo en PHP.

Sangrado y edición

No utilizo el caracter tabulador. En su lugar, empleo 3 espacios. Motivo: El caracter tabulador (t) no se muestra igual en todos los lectores de ficheros.

No utilizo más de 80 caracteres de ancho por línea. Motivo: El código es mucho más legible y cómo de imprimir.

Si una línea excede de 80 caracteres:

preg_match('expresion regular de la muerte larga larga', $cadena, $match);

quizás meto la cadena larga en una variable

$reg = 'expresion regular de la muerte larga larga';
preg_match($reg, $cadena, $match);

o si la cadena es muy larga, concateno las partes

$reg = 'expresion regular de ';
$reg .= 'la muerte larga larga';
preg_match($reg, $cadena, $match);

o si no es tan larga, divido en lineas la función

preg_match('expresion regular de la muerte larga larga',
   $cadena, $match);

¿Y con los ifs de muchas condiciones que sobrepasan los 80 caracteres?

if ($condicion1 && $condicion2 && $condicion3 && $condicion4) {
   // código
}

pasa a ser

if ($condicion1 &&
   $condicion2 &&
   $condicion3 &&
   $condicion4)
{
   // código
}

Bloques de código

Las llaves, para definir bloques de código, siempre las coloco así:

expresión {
   // código
}

salvo que la expresión exceda de 80 caracteres, en cuyo caso lo hago así:

expresión larga
   muy larga
{
   // código
}

En este segundo caso la razón de pasar la llave a la izquierda es poder distinguir dóde empieza el bloque de código. Sin embargo, en el primer caso lo pongo al final de la línea por costumbre.

Nombres

Por supuesto deben ser descriptivos, salvo algunas excepciones, como variables de contadores.

Los nombres de funciones, métodos y clases, siempre procuro ponerlos en CamelCase, esto es, eliminando los espacios y poniendo la primera letra de cada palabra en mayúscula. En funciones y métodos, la primera letra de todas es minúscula, y en el caso de clases, en mayúscula.

Por ejemplo

class Car {
   public function getSpeed() {
   }
}

En el caso de atributos y variables suelo emplear palabras en minúsculas delimitadas por guiones bajos, por ejemplo:

private $main_container;

Las constantes, como no, en mayúsculas.

Y por último, los nombres de ficheros, que los pongo también sustituyendo espacios por guiones bajos, por ejemplo foo_bar.php.

Cadenas de texto

Nunca empotro variables dentro de una cadena entrecomillada. Por ejemplo

"Hola $nombre, bienvenido"

Lo pondría como

'Hola ' . $nombre . ', bienvenido'

Si bien hace unos años la diferencia de rendimiento al utilizar comillas dobles o simples era muy notable, debido a que las dobles permiten interpretar las variables dentro de ellas, hoy día es un obstáculo superado para PHP. En cualquier caso, sigo prefiriendo comillas simples salvo que sea imprescindible.

Nunca separo una misma cadena en varias líneas. En su lugar concateno las partes.

Comentarios

Los ficheros, clases y métodos los documento con comentarios con phpDocumentor.

Para comentar trozos de código utilizo doble barra (//), aunque exceda dos líneas:

// Este comentario tiene dos líneas, pero
// aun así no utilizo comentarios multilínea

Para poner comentarios importantes, por ejemplo, informando de qué me queda por hacer en un código sin acabar, lo pongo con tres barras (///):

/// Terminar la validación de variables introducidas por el usuario

Y para poner avisos importantes con algo que sé que hasta dentro de un tiempo no me volveré a encontrar, pongo:

/// NOTE: recuerda eliminar este método

Miscelánea

Por último, las etiquetas de PHP <?php y ?>, que tan poquito me gustan, las escribo siempre como <?php y ?> salvo en el caso de hacer un echo, que utilizo la forma abreviada <?=$var?>. Esto último está desrecomendado, ya que por ejemplo, daría error la primera línea de un fichero en XML:

<?xml ?>

Además muchos servicios de alojamiento no permiten las etiquetas cortas de PHP.

Y respecto al importado de ficheros, tenemos include(), include_once(), require() y require_once(). Siempre utilizo los terminados en once(), ya que de ese modo puedo llamar varias veces sin preocuparme a un mismo fichero. Además, procuro usar siempre require_once() (Aunque a menudo se me olvida) pues, a diferencia de include, require lanza un error que interrumpe la ejecución. Y no queremos que nuestra aplicación continue la ejecución si falta un fichero importante :)

Algunos estándares

Cada framework y casi cada proyecto tienen su propio estándar. A continuación enumero algunos: