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 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. 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. Use indentação de 4 espaços, sem tabs. 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. 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). 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: 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_". 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: 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: Nomes de arquivos devem seguir o mapeamento para nomes de classes descrito acima. 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: 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. 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 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. Código PHP deve sempre estar delimitado de forma completa, com tags padrão do PHP: ]]> Tags curtas não são permitidas. 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. 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: A sintaxe acima é preferida ao invés de escapar os apóstrofos. A substituição de variáveis é permitida usando qualquer uma das duas formas: Por consistência, a forma a seguir não é permitida: Strings devem ser concatenadas usando o operador ".". Um espaço deve sempre ser adicionado antes e depois do operador "." para melhorar a legibilidade: 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 "=": 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: 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: 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: 'firstValue', 'secondKey' => 'secondValue');]]> 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 : 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). 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: NOTA: Passar valores por referência na declaração da função é permitido somente neste caso: 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. bar); } /** * CERTO */ public function bar() { return $this->bar; } }]]> 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: 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: 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. Para instruções "if" que incluem "elseif" ou "else", a formatação deve ser como nos exemplos: 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". 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. 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". 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: 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: Toda classe deve ter um bloco de documentação que contenha, no mínimo, as seguintes tags do phpDocumentor: 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: