PSR: Boas práticas em PHP | Parte - 1

PSR-1

Este é um padrão que compreende o que deve ser considerado os elementos de codificação padrão necessários para garantir um alto nível de interoperabilidade técnica entre o código PHP compartilho.

As palavras-chave “DEVEM”, “NÃO DEVEM”, “NECESSÁRIO”, “DEVERÃO”, “NÃO DEVEM”, “DEVEM”, “NÃO DEVEM”, “RECOMENDADO”, “PODE” e “OPCIONAL” neste documento.

Resumo:

Arquivos devem usar apenas <?phpe <?=
Os arquivos DEVEM usar apenas UTF-8 sem BOM para código PHP.
Os arquivos devem quersímbolos declare (classes, funções, constantes, etc.) ou provocar efeitos secundários (por exemplo, gerar a saída, configurações ini mudança, etc.), mas não deve fazer as duas coisas.
Namespaces e classes DEVEM seguir um PSR de “carregamento automático”: [ PSR-0, PSR-4 ].
Os nomes das classes DEVEM ser declarados em StudlyCaps.
Constantes de classe DEVEM ser declaradas em maiúsculas com separadores de sublinhado.
Os nomes dos métodos DEVEM ser declarados camelCase.

PSR-2

O objetivo desse guia é ajudar a reduzir o atrito cognitivo ao digitalizar os códigos de diferentes autores, assim, isso é feito enumerando um conjunto compartilhado de regras e expectativas sobre como formatar o código PHP.

As regras de estilo são derivadas de pontos em comum entre os vários projetos membros. Quando diversos autores colaboram em vários projetos, ajudam a ter um conjunto de diretrizes a serem usadas entre todos esses projetos, e o benefício deste guia não está nas próprias regras, mas no compartilhamento dessas regras.

Resumo:

O código DEVE seguir um “guia de estilo de codificação” PSR [ PSR-1].
Código DEVE usar 4 espaços para recuar, não tabulações.
NÃO DEVE haver um limite rígido no comprimento da linha; o limite suave DEVE ser 120 caracteres; linhas devem ter 80 caracteres ou menos.
DEVE haver uma linha em branco após a namespace declaração e DEVE haver uma linha em branco após o bloco de use declarações.
Chaves de abertura para as turmas DEVEM passar na próxima linha, e chaves de fechamento DEVEM continuar na próxima linha depois do corpo.
Chaves de abertura para métodos DEVEM passar na próxima linha, e chaves de fechamento DEVEM continuar na próxima linha depois do corpo.
A visibilidade DEVE ser declarada em todas as propriedades e métodos; abstracte final DEVE ser declarado antes da visibilidade; static DEVE ser declarado após a visibilidade.
Palavras-chave da estrutura de controle DEVEM ter um espaço após elas; chamadas de método e função NÃO DEVEM.
Chaves de abertura para estruturas de controle DEVEM seguir a mesma linha, e chaves de fechamento DEVEM continuar na próxima linha após o corpo.
Abrir parênteses para estruturas de controle NÃO DEVE ter um espaço após elas, e fechar parênteses para estruturas de controle NÃO DEVE ter um espaço antes.

PSR-3

O principal objetivo é permitir que as bibliotecas recebam um Psr\Log\ LoggerInterface com objeto e gravem logs de forma simples e universal, as estruturas e CMSs que tem necessidades personalizadas podem estender a interface para seus próprios fins, mas deve permanecer compatível com este documento, assim, garantindo que as bibliotecas de terceiros usadas por um aplicativo possam gravar logs centralizados do aplicativo.

A palavra implementor neste documento deve ser interpretada como alguém implementando o LoggerInterfacee m uma biblioteca ou estrutura relacionada a logs. Usuários de loggers são chamados de user.

Resumo:

Ele LoggerInterfaceexpõe oito métodos para gravar logs nos oito níveis do RFC 5424 (depuração, informações, aviso, aviso, erro, crítico, alerta, emergência).
Um nono método,, logaceita um nível de log como o primeiro argumento. Chamar esse método com uma das constantes de nível de log DEVE ter o mesmo resultado que chamar o método de nível específico. Chamar esse método com um nível não definido por esta especificação DEVE gerar um Psr\Log\InvalidArgumentExceptioncaso a implementação não saiba sobre o nível. Os usuários não devem usar um nível personalizado sem saber com certeza a implementação atual suporta.
Todo método aceita uma string como mensagem ou um objeto com um __toString()método. Os implementadores PODEM ter tratamento especial para os objetos passados. Se não for esse o caso, os implementadores DEVEM convertê-lo em uma string.
A mensagem PODE conter espaços reservados que os implementadores PODEM substituir com valores da matriz de contexto.

PSR-4

Esse PSR fala sobre uma especificação para o carregamento automático de classes a partir de caminhos de arquivos, que são totalmente Interoperável e pode ser usado de qualquer outra especificação de carregamento automático. Este PSR descreve onde colocar os arquivos que serão carregados automaticamente de acordo com especificação.

Resumo:

O termo “classe” refere-se a classes, interfaces, características e outras estruturas semelhantes.
Um nome de classe totalmente qualificado tem o seguinte formato: \<NamespaceName>(\<SubNamespaceNames>)*\<ClassName>
O nome completo da classe DEVE ter um nome de namespace de nível superior, também conhecido como “namespace de fornecedor”.
O nome completo da classe PODE ter um ou mais nomes de subdomínios.
O nome completo da classe DEVE ter um nome de classe final.
Os sublinhados não têm significado especial em nenhuma parte do nome completo da classe.
Caracteres alfabéticos no nome completo da classe PODEM ser qualquer combinação de letras minúsculas e maiúsculas.
Todos os nomes de classe DEVEM ser referenciados de maneira sensível a maiúsculas e minúsculas.
Ao carregar um arquivo que corresponde a um nome de classe totalmente qualificado…
Uma série contígua de um ou mais nomes de namespace e sub-namespace iniciais, sem incluir o separador de namespace principal, no nome completo da classe (um “prefixo de namespace”) corresponde a pelo menos um “diretório base”.
Os nomes contíguos do subdomínio após o “prefixo do namespace” correspondem a um subdiretório dentro de um “diretório base”, no qual os separadores do namespace representam separadores de diretório. O nome do subdiretório DEVE corresponder ao caso dos nomes dos subdomínios.
O nome da classe final corresponde a um nome de arquivo que termina em .php. O nome do arquivo DEVE corresponder ao caso do nome da classe final.
As implementações do Autoloader NÃO DEVEM gerar exceções, NÃO DEVEM gerar erros de qualquer nível e NÃO DEVEM retornar um valor.