Cuando una cadena es literal (no contiene sustituciones de variables), siempre debe usarse el apóstrofo o "comilla simple" para delimitar la cadena:

$a = 'Example String';

Cuando una cadena literal contiene apóstrofos, está permitido delimitar la cadena con comillas o "comillas dobles". Esto es especialmente útil para las sentencias SQL:

$sql = "SELECT `id`, `name` from `people` "
     . "WHERE `name`='Fred' OR `name`='Susan'";

Esta sintaxis se prefiere a escapar los apóstrofos ya que resulta mucho más fácil de leer.

La sustitución de variables está permitida usando cualquiera de estas formas:

$greeting = "Hello $name, welcome back!";

$greeting = "Hello {$name}, welcome back!";

Por consistencia, esta forma no está permitida:

$greeting = "Hello ${name}, welcome back!";

Las cadenas deben concatenarse usando el operador ".". Siempre debe agregarse un espacio antes y después del operador "." para mejorar la legibilidad:

$company = 'Zend' . ' ' . 'Technologies';

Al concatenar cadenas con el operador ".", se recomienda dividir la sentencia en varias líneas para mejorar la legibilidad. En estos casos, cada línea sucesiva debe rellenarse con espacios en blanco de manera que el operador "." quede alineado bajo el operador "=":

$sql = "SELECT `id`, `name` FROM `people` "
     . "WHERE `name` = 'Susan' "
     . "ORDER BY `name` ASC ";

No se permiten números negativos como índices.

Un arreglo indexado puede comenzar con cualquier número no negativo, sin embargo se desaconsejan todos los índices base distintos de 0.

Al declarar arreglos indexados con la función Array, debe agregarse un espacio final después de cada delimitador de coma para mejorar la legibilidad:

$sampleArray = array(1, 2, 3, 'Zend', 'Studio');

Está permitido declarar arreglos indexados en varias líneas usando la construcción "array". En este caso, cada línea sucesiva debe rellenarse con espacios de manera que el inicio de cada línea quede alineado:

$sampleArray = array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500);

Alternativamente, el primer elemento del arreglo puede comenzar en la línea siguiente. En ese caso, debe rellenarse con un nivel de indentación mayor que la línea que contiene la declaración del arreglo, y todas las líneas sucesivas deben tener la misma indentación; el paréntesis de cierre debe ir en una línea propia al mismo nivel de indentación que la línea que contiene la declaración del arreglo:

$sampleArray = array(
    1, 2, 3, 'Zend', 'Studio',
    $a, $b, $c,
    56.44, $d, 500,
);

Al usar esta última declaración, se recomienda utilizar una coma final para el último elemento del arreglo; esto minimiza el impacto de agregar nuevos elementos en líneas sucesivas, y ayuda a garantizar que no se produzcan errores de análisis debido a una coma faltante.

Al declarar arreglos asociativos con la construcción Array, se recomienda dividir la sentencia en varias líneas. En este caso, cada línea sucesiva debe rellenarse con espacios en blanco de manera que tanto las claves como los valores queden alineados:

$sampleArray = array('firstKey'  => 'firstValue',
                     'secondKey' => 'secondValue');

Alternativamente, el primer elemento del arreglo puede comenzar en la línea siguiente. En ese caso, debe rellenarse con un nivel de indentación mayor que la línea que contiene la declaración del arreglo, y todas las líneas sucesivas deben tener la misma indentación; el paréntesis de cierre debe ir en una línea propia al mismo nivel de indentación que la línea que contiene la declaración del arreglo. Para mejorar la legibilidad, los distintos operadores de asignación "=>" deben rellenarse de manera que queden alineados.

$sampleArray = array(
    'firstKey'  => 'firstValue',
    'secondKey' => 'secondValue',
);

Al usar esta última declaración, se recomienda utilizar una coma final para el último elemento del arreglo; esto minimiza el impacto de agregar nuevos elementos en líneas sucesivas, y ayuda a garantizar que no se produzcan errores de análisis debido a una coma faltante.

Las clases deben nombrarse de acuerdo con las convenciones de nomenclatura de Zend Framework.

La llave siempre debe escribirse en la línea debajo del nombre de la clase.

Toda clase debe tener un bloque de documentación conforme al estándar de PHPDocumentor.

Todo el código dentro de una clase debe indentarse con cuatro espacios.

Solo se permite una clase por cada archivo PHP.

Está permitido, pero desaconsejado, colocar código adicional en los archivos de clases. En dichos archivos, dos líneas en blanco deben separar la clase de cualquier código PHP adicional en el archivo de clase.

A continuación se muestra un ejemplo de declaración de clase aceptable:

/**
 * Documentation Block Here
 */
class SampleClass
{
    // all contents of class
    // must be indented four spaces
}

Las clases que extienden otras clases o que implementan interfaces deben declarar sus dependencias en la misma línea cuando sea posible.

class SampleClass extends FooAbstract implements BarInterface
{
}

Si como resultado de tales declaraciones, la longitud de la línea excede la longitud máxima de línea, corte la línea antes de las palabras clave "extends" y/o "implements", y rellene esas líneas con un nivel de indentación adicional.

class SampleClass
    extends FooAbstract
    implements BarInterface
{
}

Si la clase implementa varias interfaces y la declaración excede la longitud máxima de línea, corte después de cada coma que separa las interfaces, y sangre los nombres de las interfaces de manera que queden alineados.

class SampleClass
    implements BarInterface,
               BazInterface
{
}

Las variables miembro deben nombrarse según las convenciones de nomenclatura de variables de Zend Framework.

Cualquier variable declarada en una clase debe listarse en la parte superior de la clase, encima de la declaración de cualquier método.

La construcción var no está permitida. Las variables miembro siempre declaran su visibilidad usando uno de los modificadores private, protected, o public. Otorgar acceso directo a las variables miembro declarándolas como públicas está permitido pero se desaconseja en favor de métodos de acceso (set & get).

Las funciones deben nombrarse de acuerdo con las convenciones de nomenclatura de funciones de Zend Framework.

Los métodos dentro de las clases siempre deben declarar su visibilidad usando uno de los modificadores private, protected, o public.

Al igual que con las clases, la llave siempre debe escribirse en la línea debajo del nombre de la función. No se permite espacio entre el nombre de la función y el paréntesis de apertura para los argumentos.

Las funciones en el ámbito global están fuertemente desaconsejadas.

A continuación se muestra un ejemplo de una declaración de función aceptable dentro de una clase:

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar()
    {
        // all contents of function
        // must be indented four spaces
    }
}

En los casos en que la lista de argumentos exceda la longitud máxima de línea, puede introducir saltos de línea. Los argumentos adicionales de la función o método deben indentarse un nivel adicional respecto a la declaración de la función o método. Debe producirse entonces un salto de línea antes del paréntesis de cierre del argumento, el cual debe colocarse en la misma línea que la llave de apertura de la función o método con un espacio separando ambos, y al mismo nivel de indentación que la declaración de la función o método. El siguiente es un ejemplo de una de estas situaciones:

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar($arg1, $arg2, $arg3,
        $arg4, $arg5, $arg6
    ) {
        // all contents of function
        // must be indented four spaces
    }
}

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar(&$baz)
    {}
}

El paso por referencia en tiempo de llamada está estrictamente prohibido.

El valor de retorno no debe encerrarse entre paréntesis. Esto puede dificultar la legibilidad, además de romper el código si un método se modifica posteriormente para devolver por referencia.

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * WRONG
     */
    public function bar()
    {
        return($this->bar);
    }

    /**
     * RIGHT
     */
    public function bar()
    {
        return $this->bar;
    }
}

Los argumentos de las funciones deben separarse mediante un único espacio final después del delimitador de coma. A continuación se muestra un ejemplo de una invocación aceptable de una función que recibe tres argumentos:

threeArguments(1, 2, 3);

El paso por referencia en tiempo de llamada está estrictamente prohibido. Vea la sección de declaraciones de funciones para conocer la forma correcta de pasar argumentos por referencia.

Al pasar arreglos como argumentos a una función, la llamada a la función puede incluir la indicación "array" y puede dividirse en varias líneas para mejorar la legibilidad. En tales casos, siguen aplicando las pautas normales para escribir arreglos:

threeArguments(array(1, 2, 3), 2, 3);

threeArguments(array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500), 2, 3);

threeArguments(array(
    1, 2, 3, 'Zend', 'Studio',
    $a, $b, $c,
    56.44, $d, 500
), 2, 3);

Las sentencias de control basadas en las construcciones if y elseif deben tener un único espacio antes del paréntesis de apertura de la condición y un único espacio después del paréntesis de cierre.

Dentro de las sentencias condicionales entre los paréntesis, los operadores deben separarse mediante espacios para mejorar la legibilidad. Se recomiendan los paréntesis internos para mejorar la agrupación lógica en expresiones condicionales más grandes.

La llave de apertura se escribe en la misma línea que la sentencia condicional. La llave de cierre siempre se escribe en su propia línea. Cualquier contenido dentro de las llaves debe indentarse usando cuatro espacios.

if ($a != 2) {
    $a = 2;
}

Si la sentencia condicional provoca que la longitud de la línea exceda la longitud máxima de línea y tiene varias cláusulas, puede dividir la condición en varias líneas. En ese caso, corte la línea antes de un operador lógico, y rellene la línea de manera que quede alineada bajo el primer carácter de la cláusula condicional. El paréntesis de cierre de la condición se colocará entonces en una línea con la llave de apertura, con un espacio separando ambos, a un nivel de indentación equivalente al de la sentencia de control de apertura.

if (($a == $b)
    && ($b == $c)
    || (Foo::CONST == $d)
) {
    $a = $d;
}

La intención de este último formato de declaración es evitar problemas al agregar o quitar cláusulas de la condición en revisiones posteriores.

Para las sentencias "if" que incluyen "elseif" o "else", las convenciones de formato son similares a la construcción "if". Los siguientes ejemplos muestran el formato adecuado para sentencias "if" con construcciones "else" y/o "elseif":

if ($a != 2) {
    $a = 2;
} else {
    $a = 7;
}

if ($a != 2) {
    $a = 2;
} elseif ($a == 3) {
    $a = 4;
} else {
    $a = 7;
}

if (($a == $b)
    && ($b == $c)
    || (Foo::CONST == $d)
) {
    $a = $d;
} elseif (($a != $b)
          || ($b != $c)
) {
    $a = $c;
} else {
    $a = $b;
}

PHP permite escribir sentencias sin llaves en algunas circunstancias. Este estándar de codificación no hace diferenciación alguna: todas las sentencias "if", "elseif" o "else" deben usar llaves.

Las sentencias de control escritas con la sentencia "switch" deben tener un único espacio antes del paréntesis de apertura de la condición y después del paréntesis de cierre.

Todo el contenido dentro de la sentencia "switch" debe indentarse usando cuatro espacios. El contenido bajo cada sentencia "case" debe indentarse usando cuatro espacios adicionales.

switch ($numPeople) {
    case 1:
        break;

    case 2:
        break;

    default:
        break;
}

La construcción default nunca debe omitirse de una sentencia switch.

Todos los bloques de documentación ("docblocks") deben ser compatibles con el formato de phpDocumentor. Describir el formato de phpDocumentor está fuera del alcance de este documento. Para más información, visite: http://phpdoc.org/

Todos los archivos de clases deben contener un docblock de "nivel de archivo" en la parte superior de cada archivo y un docblock de "nivel de clase" inmediatamente encima de cada clase. Se pueden encontrar ejemplos de estos docblocks a continuación.

Todo archivo que contenga código PHP debe tener un docblock en la parte superior del archivo que contenga como mínimo estas etiquetas de phpDocumentor:

/**
 * Short description for file
 *
 * Long description for file (if any)...
 *
 * LICENSE: Some license information
 *
 * @category   Zend
 * @package    Zend_Magic
 * @subpackage Wand
 * @copyright  Copyright (c) 2005-2015 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license   BSD License
 * @version    $Id:$
 * @link       http://framework.zend.com/package/PackageName
 * @since      File available since Release 1.5.0
*/

La anotación @category debe tener el valor "Zend".

La anotación @package debe asignarse, y debería ser equivalente al nombre del componente de la clase contenida en el archivo; típicamente, esto tendrá solo dos segmentos, el prefijo "Zend", y el nombre del componente.

La anotación @subpackage es opcional. Si se proporciona, debería ser el nombre del subcomponente, sin el prefijo de la clase. En el ejemplo anterior, se asume que la clase en el archivo es "Zend_Magic_Wand", o usa ese nombre de clase como parte de su prefijo.

Toda clase debe tener un docblock que contenga como mínimo estas etiquetas de phpDocumentor:

/**
 * Short description for class
 *
 * Long description for class (if any)...
 *
 * @category   Zend
 * @package    Zend_Magic
 * @subpackage Wand
 * @copyright  Copyright (c) 2005-2015 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license   BSD License
 * @version    Release: @package_version@
 * @link       http://framework.zend.com/package/PackageName
 * @since      Class available since Release 1.5.0
 * @deprecated Class deprecated in Release 2.0.0
 */

La anotación @category debe tener el valor "Zend".

La anotación @package debe asignarse, y debería ser equivalente al componente al que pertenece la clase; típicamente, esto tendrá solo dos segmentos, el prefijo "Zend", y el nombre del componente.

La anotación @subpackage es opcional. Si se proporciona, debería ser el nombre del subcomponente, sin el prefijo de la clase. En el ejemplo anterior, se asume que la clase descrita es "Zend_Magic_Wand", o usa ese nombre de clase como parte de su prefijo.

Toda función, incluyendo los métodos de objeto, debe tener un docblock que contenga como mínimo:

No es necesario usar la etiqueta "@access" porque el nivel de acceso ya se conoce a partir del modificador "public", "private" o "protected" usado para declarar la función.

Si una función o método puede lanzar una excepción, use @throws para todas las clases de excepción conocidas:

@throws exceptionclass [description]