A.4. Estilo de Código

A.4.1. Demarcação de Código PHP

Código PHP deve sempre estar delimitado de forma completa, com tags padrão do PHP:

<?php

?>

Tags curtas não são permitidas.

A.4.2. Strings

A.4.2.1. String Literal

Quando uma string é literal (não contém substituições de variável), deve ser usado apóstrofo ou aspas simples para demarcar o texto.

$a = 'Exemplo de Texto';

A.4.2.2. String Literal Contendo Apóstrofos

Quando uma string literal contém apóstrofos dentro de si, é permitido demarcar o texto com aspas ou "aspas duplas". Isto é especialmente encorajado para declarações SQL:

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

A sintaxe acima é preferida ao invés de escapar os apóstrofos.

A.4.2.3. Substituição de Variáveis

A substituição de variáveis é permitida usando qualquer uma das duas formas:

$greeting = "Olá $nome, bem-vindo de volta!";

$greeting = "Olá {$nome}, bem-vindo de volta!";

Por consistência, a forma a seguir não é permitida:

$greeting = "Olá ${nome}, bem-vindo de volta!";

A.4.2.4. Concatenação de String

Strings devem ser concatenadas usando o operador ".". Um espaço deve sempre ser adicionado antes e depois do operador "." para melhorar a legibilidade:

$company = 'Zend' . 'Technologies';

Quando estiver concatenando strings com o operador ".", é permitido quebrar a declaração em várias linhas para melhorar a legibilidade. Nestes casos, cada linha sucessiva deverá ser colocada num bloco com espaço em branco de forma que o operador "." esteja alinhado abaixo do operador "=":

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

A.4.3. Arrays

A.4.3.1. Arrays Indexados Numericamente

Números negativos não são permitidos como índices.

Um array indexado pode começar com qualquer número não negativo, porém isto é desencorajado. É recomendado que todo array tenha um índice inicial 0.

Quando declarar arrays indexados com o construtor array, um espaço deve ser adicionado depois de cada vírgula para melhorar a legibilidade:

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

Também é permitido declarar arrays indexados em várias linhas usando o construtor "array". Neste caso, cada linha sucessiva deve ser colocada num bloco com espaços de forma que o início de cada código alinhe-se conforme mostrado abaixo:

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

A.4.3.2. Arrays Associativos

Quando declarar arrays associativos com o construtor array, é recomendado quebrar a declaração em múltiplas linhas. Neste caso, cada linha sucessiva deve estar num bloco com espaço em branco, de forma que as chaves e valores estejam alinhados:

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

A.4.4. Classes

A.4.4.1. Declaração de Classes

Classes devem ser nomeadas seguindo a convenção de nomes.

A chave de abertura é sempre escrita embaixo do nome da classe (forma de "uma única chave real").

Toda classe deve ter um bloco de documentação, dentro do padrão do PHPDocumentor.

Todo código dentro de uma classe deve estar indentado com quatro espaços.

Somente uma classe é permitida por arquivo PHP.

Colocar código adicional em um arquivo de classe é permitido mas desencorajado. Nestes arquivos, duas linhas em branco devem separar a classe do código PHP adicional no arquivo.

Este é um exemplo de declaração aceitável de classe :

/**
 * Bloco de documentação aqui
 */
class SampleClass
{
    // conteúdo completo da classe
    // deve estar indentado com quatro espaços
}

A.4.4.2. Variáveis Membros de Classe

Variáveis membro devem ser nomeadas de acordo com a convenção de nomes de variáveis.

Quaisquer variáveis declaradas numa classe devem ser listadas no topo da classe, antes de declarar qualquer função.

O construtor var não é permitido. Variáveis membro sempre declaram sua visibilidade usando o construtor private, protected ou public. Acessar variáveis membro diretamente tornando-as públicas é permitido mas desencorajado em favor de variáveis de acesso (set/get).

A.4.5. Funções e Métodos

A.4.5.1. Declaração de Funções e Métodos

Nomes de funções devem seguir a convenção de nomes.

Funções dentro de classes sempre declaram sua visibilidade usando o construtor private, protected ou public.

Como classes, a chave de abertura deve sempre ser escrita abaixo do nome da função (forma de "uma única chave real"). Não há espaços entre o nome da função e os parênteses para os argumentos.

Funções no escopo global são fortemente desencorajadas.

Este é um exemplo de declaração aceitável de função:

/**
 * Bloco de documentação aqui
 */
 class foo

    /**
    * Bloco de documentação aqui
    */
    public function bar()
    {
        // todo conteúdo da função
        // deve ser indentado com quatro espaços
    }
}

NOTA: Passar valores por referência na declaração da função é permitido somente neste caso:

/**
 * Bloco de documentação aqui
 */
 class foo

    /**
    * Bloco de documentação aqui
    */
    public function bar(&$baz)
    {
        // todo conteúdo da função
        // deve ser indentado com quatro espaços
    }
}

Passar valores por referência ao chamar a função é proibido.

O valor de retorno não deve estar entre parênteses. Isto pode impedir a boa legibilidade e pode ainda quebrar o código de um método que seja alterado posteriormente para retornar por referência.

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

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

A.4.5.2. Uso de Funções e Métodos

Argumentos de funções são separados por um espaço simples depois da vírgula. Este é um exemplo de chamada de função que tenha três argumentos:

threeArguments(1, 2, 3);

Passar parâmetros por referência na chamada da função é proibido. Veja a seção de declaração de funções para o modo correto de passar argumentos por referência.

Para funções que permitem arrays nos argumentos, a chamada da função pode incluir o construtor "array" e pode ser dividido em várias linhas para melhorar a legibilidade. Nestes casos, o padrão para escrever arrays também se aplica:

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

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

A.4.6. Instruções de Controle

A.4.6.1. If / Else / Elseif

Instruções de controle baseadas nos construtores if e elseif devem ter um espaço simples antes do parêntese de abertura da condição e um espaço simples depois do parêntese de fechamento.

Dentro das declarações condicionais entre os parênteses, operadores devem ser separados por espaços para legibilidade. Parênteses internos são encorajados para melhorar o agrupamento lógico de condicionais extensas.

A chave de abertura é sempre escrita na mesma linha da instrução condicional. A chave de fechamento é sempre escrita em sua própria linha. Qualquer conteúdo dentro das chaves deve ser indentado por quatro espaços.

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

Para instruções "if" que incluem "elseif" ou "else", a formatação deve ser como nos exemplos:

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


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

O PHP permite, em certas circunstâncias, que as instruções sejam escritas sem as chaves. O padrão de código não as diferencia, pois todas instruções "if", "elseif" ou "else" devem utilizar as chaves.

O uso do construtor "elseif" é permitido mas altamente desencorajado em favor da combinação "else if".

A.4.6.2. Switch

Instruções de controle escritas com o construtor "switch" devem ter um espaço simples antes do parêntese de abertura da instrução condicional e um espaço simples depois do parêntese de fechamento.

Todo conteúdo da instrução "switch" deve ser indentado com quatro espaços. O conteúdo abaixo de cada instrução "case" deve ser indentado com quatro espaços adicionais.

switch ($numPeople) {
    case 1:
        break;

    case 2:
        break;

    default:
        break;
}

O construtor default jamais pode ser omitido da instrução switch.

NOTA: Algumas vezes é útil escrever uma instrução case que entra no próximo case sem incluir um break ou return. Para distinguir aqueles cases dos bugs, qualquer instrução case onde break ou return são omitidos deve conter o comentário "// break intentionally omitted".

A.4.7. Documentação Inline

A.4.7.1. Formato da Documentação

Todos blocos de documentação ("dockblocks") devem ser compatíveis com o formato do phpDocumentor. A descrição do formato do phpDocumentor está além do escopo deste documento. Para maiores informações, visite: http://phpdoc.org">

Todo código fonte escrito para o Framework Zend ou que trabalhe com o framework deve conter um bloco de documentação em nível de arquivo no topo de cada arquivo e um bloco de documentação em nível de classe imediatamente acima de cada classe. Abaixo seguem exemplos destes blocos de documentação:

A.4.7.2. Arquivos

Cada arquivo que contenha código PHP deve ter um bloco de cabeçalho no topo do arquivo que contenha, no mínimo, estas tags do phpDocumentor:

/**
 * Short description for file
 *
 * Long description for file (if any)...
 *
 * LICENSE: Some license information
 *
 * @copyright  2005 Zend Technologies
 * @license    http://www.zend.com/license/3_0.txt   PHP License 3.0
 * @version    CVS: $Id:$
 * @link       http://dev.zend.com/package/PackageName
 * @since      File available since Release 1.2.0
*/

A.4.7.3. Classes

Toda classe deve ter um bloco de documentação que contenha, no mínimo, as seguintes tags do phpDocumentor:

/**
 * Short description for class
 *
 * Long description for class (if any)...
 *
 * @copyright  2005 Zend Technologies
 * @license    http://www.zend.com/license/3_0.txt   PHP License 3.0
 * @version    Release: @[email protected]
 * @link       http://dev.zend.com/package/PackageName
 * @since      Class available since Release 1.2.0
 * @deprecated Class deprecated in Release 2.0.0
 */

A.4.7.4. Funções

Toda função, incluindo métodos de objetos, deve ter um bloco de documentação que contenha, no mínimo, as seguintes tags:

  • Descrição da função

  • Todos argumentos

  • Todos os possíveis valores de retorno

Não é necessário usar a tag "@access" pois o nível de acesso é conhecido através do construtor "public", "private", ou "protected" usado para declarar a função.

Se uma função/método pode gerar uma excessão, use @throws:

@throws exceptionclass [description]