Guía estilo de programación.

...

Tanto la clase como los métodos y propiedades deben estar documentados. Así mismo, en la clase deben existir los elementos @author y @version de la documentación aunque se pueden incluir más como @internal, @since, etc. En caso de que un clase extienda otra o implemente una interfaz, la extensión debe estar en la misma línea que el nombre de la clase. Los modificadores de clase o de método, como abstract, static, etc., también deben estar en la misma línea que el nombre que modifican. Los nombres de las interfaces, por convención, deben comenzar por "I" mayúscula, por ejemplo: IConfig.

Código Fuente

/** * Documentación para la clase 'MiClaseDeEjemplo'. * * @author Diego Lago * @version 0.1 2008-09-11 */ class MiClaseDeEjemplo extends MiClaseBase implements MiInterface {

private static $campo1; private $campo2;

static function miMetodo1() { }

/** * Documentación para el método 'miMetodoDos'.

* * @param mixed $param1 El primer parámetro. * @param mixed $param2 El segundo parámetro. * * @return mixed Valor de retorno. */ function miMetodoDos($param1,$param2) { }

} ?>

Constantes Las constantes dentro de una clase se deben declarar todas en mayúsculas y las diferentes palabras que la compongan separadas por barras bajas (_). Por ejemplo:

Código Fuente

const ESTO_ES_UNA_CONSTANTE = 0;

Otra forma también permitida aunque no recomendada es que las constantes estén escritas en UpperCamelCase pero que siempre comiencen por la letra "k" minúscula. Por ejemplo:

Código Fuente

const kEstoEsUnaConstante = 0;

En caso de que haya varias constantes dentro de la clase, las que estén relacionadas deben tener los valores a la misma altura. Por

ejemplo:

Código Fuente

const ENGINE_MSSQL = "mssql"; // Microsoft SQL const ENGINE_MYSQL = "mysql"; // MySQL const ENGINE_PGSQL = "pgsql"; // Postgre SQL const ENGINE_FIREBIRD = "firebird"; // Firebird const ENGINE_ORACLE = "oci"; // Oracle Call Interface const ENGINE_ODBC = "odbc"; // Open Database Connectivity const ENGINE_SQLITE = "sqlite"; // SQLite

Los comentarios de las constantes también deberían estar alineados verticalmente. En el caso de que existen varias constantes que no estén relacionadas, estas deberían estar separadas por una línea en blanco. Variables Las variables de las clases, al igual que las variables normales, deben estar escritas en lowerCamelCase. Además, es recomendable declarar cada variable en una línea diferente junto con su modificador de acceso (public, private, protected). Por ejemplo:

Código Fuente

public $primeraVariable; private $unaVariablePrivada; protected $variableProtegidaParaMisSubclases;

En caso de que existan varias variables relacionadas que requieran un

valor de inicialización, éstas, al igual que las constantes, deben tener dichos valores alineados verticalmente. Métodos Los métodos de las clases, al igual que las funciones normales, deben estar escritos en lowerCamelCase. La forma de escribir los parámetros y el cuerpo es la misma que para las funciones normales. Además, a las funciones hay que incorporarles su modificador de acceso aunque, en el caso de que sean públicas, no es necesario incluirlo. Por ejemplo:

Código Fuente

private function getRealName() { // código } Operadores

Los operadores, como +, +=, -, -=, *, *=, /, /=, %, %=, =, ==, ===, !=, >, >=, >>, , &, &&, |, ||, ?, etc., deben escribirse con espacios a ambos lados. Por ejemplo:

Código Fuente

$miVariable = $otraVariable + 1 - ($pi * 3);

Una excepción a esta regla son los operadores unarios ++ y -- donde

no es necesario (ni recomendable) poner un espacio antes (o después, según sea de postincremento o preincremento) de la variable que modifican. El siguiente ejemplo sería correcto:

Código Fuente

$miVariableNumerica++;

Estas reglas de separación son útiles, por ejemplo, cuando existen varias expresiones que pueden dar lugar a ambigüedad:

Código Fuente

$a = $b+++++$c;

La expresión anterior, si se siguen las directrices de separación de operadores, tendría la forma:

Código Fuente

$a = $b++ + ++$c;

De esta forma el programador distingue perfectamente lo que hace la expresión anterior. Expresiones booleanas

Cuando se comprueba una expresión y esta devuelve un valor booleano, es preferible hacerlo en una operación lógica booleana en lugar de introducirlo en una estructura de control de tipo if. Por

ejemplo, en el siguiente código:

Código Fuente

if($a > 100 && $b

Es más recomendable hacerlo de la siguiente forma:

Código Fuente

return ($a > 100 && $b

Esto es por mera sintaxis ya que el compilador genera el mismo código objeto para ambas expresiones. Siempre que sea posible, se deberán utilizar valores booleanos en lugar de números, es decir, si una variable es booleana, no se le debe asignar "0" para false y "1" para true. Se le deben asignar las construcciones del lenguaje true y false. Estructuras de control

Las estructuras de control son aquellas instrucciones del lenguaje que controlan el flujo de ejecución, es decir, sentencias que deciden qué ejecutar en cada caso, bucles