# Padrões de Codificação do Framework Zend para PHP

## Visão Geral

### Escopo

Este documento provê as linhas principais e recursos para desenvolvedores e times de desenvolvimento no Framework da Zend. São cobertos os seguintes assuntos:

- Formato do Arquivo PHP

- Convenção de Nomes

- Estilo de Código

- Documentação Inline

### Objetivos

Bons padrões de código são importantes em qualquer projeto de desenvolvimento, mas particularmente quando múltiplos desenvolvedores estão trabalhando no mesmo projeto. Ter padrões ajuda a assegurar que o código seja de alta qualidade, tenha poucos bugs e seja de fácil manutenção.

## Formato do Arquivo PHP

### Geral

Para arquivos que contenham somente código PHP, a tag de fechamento ("?>") não é permitida. Ela não é requerida pelo PHP. Não incluir esta tag evita espaços em branco na saída, deixados acidentalmente.

IMPORTANTE:A inclusão de dados binários arbitrários, como o permitido por `__HALT_COMPILER()` é proibido em qualquer framework Zend, arquivo PHP ou arquivos derivados deles. O uso desta funcionalidade só é permitida para scripts especiais de instalação.

### Indentação

Use indentação de 4 espaços, sem tabs.

### Tamanho máximo de linha

A intenção é utilizar linhas com 80 caracteres, por exemplo, desenvolvedores devem procurar manter seu código próximo a 80 colunas se isso for prático. De qualquer forma, linhas longas são aceitáveis. O tamanho máximo de uma linha de código PHP é de 120 caracteres.

### Final de Linha

O final de linha segue o padrão para arquivos texto no Unix. Linhas devem acabar somente com um linefeed (LF). Linefeeds são representados como ordinal 10, ou hexadecimal 0x0A.

Não use retorno de carro (CR)como nos computadores Macintosh (0x0D).

Não use a combinação de retorno de carro/linefeed (CRLF) como nos computadores Windows (0x0D, 0x0A).

## Convenções de Nomes

### Classes

O Framework Zend emprega uma convenção por meio dos nomes das classes, diretamente mapeados aos diretórios nos quais estão arquivados. O diretório raiz do Framework Zend é o diretório "Zend/", abaixo do qual todas as classes são arquivadas hierarquicamente.

Nomes de classes podem conter somente caracteres alfanuméricos. Números em nomes de classes são permitidos, mas desencorajados. Sublinhados são permitidos somente no lugar do separador de caminho -- o nome do arquivo "Zend/Db/Table.php" deve ser mapeado para o nome de classe "Zend_Db_Table".

Se o nome de uma classe é composto por mais de uma palavra, a primeira letra de cada nova palavra deve ser maiúscula. Letras maiúsculas sucessivas não são permitidas, por exemplo a classe "Zend_PDF" não é permitida enquanto "Zend_Pdf" é aceita.

As classes do Framework Zend de autoria da Zend ou de uma das companhias parceiras participantes e distribuídas com o Framework devem sempre iniciar com "Zend_" e devem estar arquivadas sob a hierarquia do diretório "Zend/".

São exemplos de nomes aceitáveis para classes:

    Zend_Db

    Zend_View

    Zend_View_Helper

IMPORTANTE: Código que opera com o framework mas que não é parte dele, por exemplo, código escrito por um usuário final e não pela Zend ou uma das companhias parceiras, não pode começar com "Zend_".

### Interfaces

Classes de interface devem seguir as mesmas convenções como outras classes (veja acima), porém deve acabar com a palavra "Interface", como nestes exemplos:

    Zend_Log_Adapter_Interface
    Zend_Controller_Dispatcher_Interface

### Nomes de Arquivos

Para todos os outros arquivos, somente caracteres alfanuméricos, sublinhado, e traço "-" são permitidos. Espaços e ponto são proibidos.

Qualquer arquivo que contenha qualquer código PHP deve acabar com a extensão ".php". Estes exemplos mostram nomes de arquivo aceitáveis para as classes que estes contenham, baseados nos exemplos da seção acima:

    Zend/Db.php

    Zend/Controller/Front.php

    Zend/View/Helper/FormRadio.php

Nomes de arquivos devem seguir o mapeamento para nomes de classes descrito acima.

### Funções e Métodos

Nomes de funções devem conter somente caracteres alfanuméricos. Sublinhados não são permitidos. Números são permitidos nos nomes, mas são desencorajados.

Nomes de funções devem sempre começar com letra minúscula. Quando um nome consistir em mais de uma palavra, a primeira letra de cada nova palavra deve ser maiúscula. Isto é comumente chamado o método "studlyCaps" ou "camelCaps".

Verbalização é encorajada. Nomes de funções devem ser tão longos quanto práticos para melhorar o entendimento do código.

Estes são exemplos de nomes aceitáveis para funções:

    filterInput()

    getElementById()

    widgetFactory()

Para programação orientada ao objeto, acessores para objetos devem sempre ser prefixados com "get" ou "set". Quando usando padrões de projeto, como o Singleton ou Factory Patterns, o nome do método deve conter o nome do padrão, como prática para que o padrão seja reconhecido na leitura.

Funções no escopo global ("funções soltas") são permitidas mas desencorajadas. É recomendável que estas funções sejam empacotadas numa classe estática.

### Variáveis

Nomes de variáveis devem conter somente caracteres alfanuméricos. Sublinhados não são permitidos. Números são permitidos nos nomes, mas desencorajados.

Para variáveis membros de classes que são declaradas com o construtor "private" ou "protected", o primeiro caractere do nome da variável deve ser um único sublinhado. Este é o único uso aceitável de sublinhado no nome. Variáveis membros declaradas "public" não podem começar com sublinhado.

Como nos nomes de funções (veja a seção 3.3 acima) nomes de variáveis devem iniciar com uma letra minúscula e seguir a convenção "camelCaps".

Verbalização é encorajada. Nomes de variáveis devem ser tão longos quanto práticos. Nomes como "$i" e "$n" são desencorajados para qualquer coisa que não esteja num contexto de loop pequeno. Se um loop contém mais de 20 linhas de código, as variáveis para os indices precisam ter um nome mais descritivo.

### Constantes

Constantes podem conter caracteres alfanuméricos e sublinhado. Números são permitidos nos nomes.

Constantes devem ter sempre todas suas letras em maiúsculo.

Constantes devem ser definidas como membros de classe usando o construtor "const". Definir constantes no escopo global com "define" é permitido, mas desencorajado.

## Estilo de Código

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

### Strings

#### 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';

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

#### 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!";

#### 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 ";

### Arrays

#### 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);

#### 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');

### Classes

#### 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
    }

#### 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).

### Funções e Métodos

#### 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;
        }
    }

#### 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);

### Instruções de Controle

#### 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".

#### 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".

### Documentação Inline

#### 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:

#### 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    $Id:$
     * @link       http://dev.zend.com/package/PackageName
     * @since      File available since Release 1.2.0
    */

#### 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: @package_version@
     * @link       http://dev.zend.com/package/PackageName
     * @since      Class available since Release 1.2.0
     * @deprecated Class deprecated in Release 2.0.0
     */

#### 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]