Dev.to

PHP PSR-12 - Resumo

O PSR-12 faz parte do PHP Starndard Recommendations e tem o intuito de reduzir fricções no desenvolvimento de software quando um sistema envolve vários desenvolvedores. Isso é feito a partir da apresentação de várias regras e expectativas sobre como um código PHP deve ser formatado, além de proporcionar o desenvolvimento de ferramentas as quais podem revisar e validar se o código se encontra conforme esperado. Essa PSR substitui o PSR-2, apresentando recomendações sobre contextos e funcionalidades mais modernas (tendo em vista que o PSR-2 foi apresentado em 2012, um contexto mais antigo). Geral Padronização de Código Básico Código deve se encontrar conforme especificidades da PSR-1 Termo 'StudlyCaps' deve ser interpretado como 'PascalCase' Arquivos Todos os arquivos PHP devem terminar com exatamente uma linha vazia (caractere \n, padrão Unix LF), precedida por uma linha não vazia com código ou comentário. A tag PHP de fechamento "?>" deve ser omitida em arquivos que contenham apenas código PHP Linhas Não deve existir um limite rigoso (ou obrigatório) para o comprimento de uma linha. Um limite tolerável (mas que em situações adequadas pode ser desconsiderado) deve ser de 120 caracteres. As linhas não deveriam ser maiores que 80 caracteres, linhas maiores deveriam ser separadas em múltiplas linhas subsequentes de não mais do que 80 linhas. Não deve existir um espaço vazio no final de uma linha. Linhas vazias podem ser adicionadas para para melhorar a legibilidade e indicar blocos relacionados de código Não devem existir mais do que um "statement" por linha. Indentação Código deve seguir indentação de 4 espaços para cada nível, não deve utilizar "tabs" Palavras Reservadas e Tipagem Todas as palavras reservadas e tipagem devem estar em lowercase (quaisquer novas palavras reservadas adicionadas no futuro, devem seguir essa convenção) Abreviações devem ser utilizadas ("bool" ao invés de "boolean" e etc) Declaração, Namespace, Import e outros Um cabeçalho de uma classe PHP pode conter inúmeros statements relacionados à importação de outros componentes (classes, funções, constantes), declaração do atual namespace, comentários e documentações, e outras informações. É necessário que essas informações estejam presentes conforme ordem a seguir : Abertura de tag PHP (

Jun 5, 2025 - 17:40
 0
PHP PSR-12 - Resumo

O PSR-12 faz parte do PHP Starndard Recommendations e tem o intuito de reduzir fricções no desenvolvimento de software quando um sistema envolve vários desenvolvedores. Isso é feito a partir da apresentação de várias regras e expectativas sobre como um código PHP deve ser formatado, além de proporcionar o desenvolvimento de ferramentas as quais podem revisar e validar se o código se encontra conforme esperado.

Essa PSR substitui o PSR-2, apresentando recomendações sobre contextos e funcionalidades mais modernas (tendo em vista que o PSR-2 foi apresentado em 2012, um contexto mais antigo).

Geral

Padronização de Código Básico

  • Código deve se encontrar conforme especificidades da PSR-1

  • Termo 'StudlyCaps' deve ser interpretado como 'PascalCase'

Arquivos

  • Todos os arquivos PHP devem terminar com exatamente uma linha vazia (caractere \n, padrão Unix LF), precedida por uma linha não vazia com código ou comentário.

  • A tag PHP de fechamento "?>" deve ser omitida em arquivos que contenham apenas código PHP

Linhas

  • Não deve existir um limite rigoso (ou obrigatório) para o comprimento de uma linha.

  • Um limite tolerável (mas que em situações adequadas pode ser desconsiderado) deve ser de 120 caracteres.

  • As linhas não deveriam ser maiores que 80 caracteres, linhas maiores deveriam ser separadas em múltiplas linhas subsequentes de não mais do que 80 linhas.

  • Não deve existir um espaço vazio no final de uma linha.

  • Linhas vazias podem ser adicionadas para para melhorar a legibilidade e indicar blocos relacionados de código

  • Não devem existir mais do que um "statement" por linha.

Indentação

  • Código deve seguir indentação de 4 espaços para cada nível, não deve utilizar "tabs"

Palavras Reservadas e Tipagem

  • Todas as palavras reservadas e tipagem devem estar em lowercase (quaisquer novas palavras reservadas adicionadas no futuro, devem seguir essa convenção)

  • Abreviações devem ser utilizadas ("bool" ao invés de "boolean" e etc)

Declaração, Namespace, Import e outros

Um cabeçalho de uma classe PHP pode conter inúmeros statements relacionados à importação de outros componentes (classes, funções, constantes), declaração do atual namespace, comentários e documentações, e outras informações. É necessário que essas informações estejam presentes conforme ordem a seguir :

  1. Abertura de tag PHP (

  2. Docblock do arquivo

  3. Um ou mais statments de declaração

  4. O namespace do arquivo

  5. Um ou mais import de classes (reconhecimento pelo statement "use")

  6. Um ou mais import de funções

  7. Um ou mais import de constantes

  8. O resto do arquivo

Cada statement deve ser separado em seu respectivo bloco, de forma que cada bloco seja separado por uma linha em branco, mas os mesmos não possuam uma linha em branco em seu conteúdo.

Essa convenção deve ser aplicada mesmo em arquivos que apresentem uma mistura de PHP e HTML em seu conteúdo.

  • A tag de abertura de PHP deve estar em linha única caso se encontre na primeira linha do arquivo.

  • Statments de importação não devem começar com a barra invertida

  • Namespaces compostos não devem ter uma profundidade maior do que 2

  • Ao declarar tipos estritos (declare(strict_types=1)) em um arquivo que misture PHP e HTML, é necessário que a declaração seja feita na primeira linha com abertura e fechamento PHP

  • Blocos de statements com a palavra chave "declare" são permitidos e devem se encontrar entre abertura e fechamento de chaves (abertura na mesma linha de palavra chave "declare" e o fechamento em uma nova linha)

Classes, Propriedades e Métodos

  • Qualquer fechamento de classe não deve ser seguido por um comentário ou statment na mesma linha

  • Os parênteses devem sempre estar presentes ao instanciar uma nova classe, mesmo que não haja argumentos a serem passados ao construtor

Extends e Implements

  • As palavra-chaves "extends" e "implements" devem ser declaradas na mesma linha em que o nome de classe

  • A abertura de chaves da classe deve se encontrar em sua própria linha, o fechamento deve estar na linha seguinte após o fim do corpo da classe

  • A abertura e o fechamento não deve suceder uma linha vazia

  • Lista de interfaces a serem implementadas ou estendidas, deve apresentar cada uma em uma nova linha com sua indentação de acordo.

Traits

  • A palavra chave "use" utilizada para implementar traits, deve ser declarada na linha seguinte à abertura de chaves da classe

  • Cada inclusão de trait deve estar em uma linha individual e deve utilizar seu próprio "use"

  • Quando a classe não tiver mais nada além do use statement da trait, o fechamento deve estar presente logo na linha seguinte do mesmo.

    • Do contrário, deve haver uma linha em branco após o "use" statement

Propriedades e Constantes

  • Visibilidade deve ser declarada em todas as propriedades e constantes (caso a versão do PHP seja maior que 7.1)

  • A palavra chave "var" não deve ser usada para declarar uma propriedade

  • Não deve haver mais do que uma palavra chave por statement

  • Propriedades privadas não devem ter seu nome prefixado com um underline para indicar sua visibilidade

  • Deve haver um espaço na declaração do tipo de variável e o nome

Métodos e Funções

  • Visibilidade deve ser declarada para todos os métodos

  • Métodos privados não devem ter seu nome prefixado com um underline para indicar sua visibilidade

  • Método e nome de função não deve ser declarado com espaço após o nome

Argumentos de Métodos e Funções

  • Na lista de argumentos, não deve existir um espaço antes de cada linha, e deve existir um espaço após cada linha.

  • Argumentos com valores definidos por padrão, devem ir no final da lista

  • Lista de argumentos podem ser divididas entre várias linhas, no qual cada linha é indentada e cada item se encontra em uma linha. Quando assim ocorrer, o primeiro item deve estar na próxima linha da abertura de parênteses.

    • Quando assim ocorrer, o fechamento de parênteses e a abertura de chaves devem estar na mesma linha com um espaço entre eles

  • Quando houver uma declaração do tipo de retorno, o mesmo deve ter um espaço antes dos dois pontos. Ambos devem estar na mesma linha do fechamento de parênteses, sem espaço entre esses.

  • Declarações de tipo nulas não devem apresentar espaço entre o sinal de interrogação e o tipo de variável.

  • Quando utilizar o operador de referência ("&"), não deve apresentar espaço entre ele e o nome da variável.

  • Não deve apresentar espaço entre o operador de argumento "variadic" ("...") e o nome do argumento

  • Ao combinar os últimos dois operadores citados, não deve haver espaço entre eles.

Abstract, final e static

  • Abstract e final devem preceder a declaração de visibilidade

  • Static deve suceder a declaração de visibilidade

Chamadas de Métodos e de Funções

  • Ao realizar a chamada de um método ou função, não deve existir a presença de nenhum espaço com exceção de um espaço em branco após as linhas que separam os argumentos

  • Listas de argumentos podem ser divididas entre várias linhas no qual cada linha deve ser um argumento indentado, o primeiro argumento deve se encontrar na linha que sucede a abertura de parênteses.

Estrutura de Controle

  • Deve haver um espaço após a palavra reservada da estrutura de controle

  • Não deve haver espaço após a abertura de parênteses

  • Não deve haver espaço anterior ao fechamento de parênteses

  • Deve haver um espaço entre a abertura e o fechamento de parênteses

  • O corpo da estrutura deve estar indentado

  • O corpo da estrutura deve estar na próxima linha após a abertura de chaves

  • O fechamento de chaves deve estar na próxima linha após o corpo

If, Elseif, Else

  • A palavra chave elseif deveria ser utilizada ao invés de else if

  • Expressões em parênteses podem ser divididas entre várias linhas no qual cada linha deve ser uma expressão indentada, a primeira expressão deve se encontrar na linha que sucede a abertura de parênteses, e operadores booleanos devem se encontrar no começo ou no fim da linha, de forma igual para todas as linhas e não uma mistura entre elas.

Switch, Case

  • "Case" statement deve estar indentado uma vez a partir do "switch", e a palavra-chave "break" deve estar indentada no mesmo nível em que o corpo do "case"

  • Deve haver um comentário como "// no break" quando existir uma sequência intencional de um case não vazio para outro

While, Do While, For

  • Expressões em parênteses podem ser divididas entre várias linhas no qual cada linha deve ser uma expressão indentada, a primeira expressão deve se encontrar na linha que sucede a abertura de parênteses, e operadores booleanos devem se encontrar no começo ou no fim da linha, de forma igual para todas as linhas e não uma mistura entre elas.

Foreach

Um foreach statement deve se parecer conforme o exemplo abaixo

 $value) {
    // foreach body
}

Try, catch, finally

Um bloco try-catch-finally deve se parecer conforme o exemplo abaixo

Operadores

Incremento / Decremento

  • Operadores de incremento e decremento não devem apresentar espaços entre estes e o operando

  • Operadores de casting (conversão de tipo) não devem apresentar espaços entre parênteses

Binários

  • Todos os operadores binários de comparação, aritmética, atribuição e lógicos devem se encontrar entre um espaço em branco e outro

Ternário

  • Deve apresentar um espaço entre os caracteres ? e :
    $variable = $foo ? 'foo' : 'bar';

  • Quando o operador utilizar sua forma abreviada (sem o operando do meio), o espaço entre os caracteres operadores deve ser omitido
    $variable = $foo ?: 'bar';

Closures

  • Devem ser declaradas com um espaço após a palavra chave 'function' e um espaço antes da palavra chave 'use'.

  • A abertura de chaves deve estar na mesma linha, e o fechamento na linha seguinte do corpo.

  • Não deve haver um espaço após a abertura e antes do fechamento de parênteses da lista de argumentos.

  • Na lista de argumentos, não deve haver um espaço antes de cada vírgula, mas sim um espaço após cada vírgula.

  • Argumentos com valores 'padrão' devem se encontrar no final da lista de argumentos

  • Se um tipo de retorno estiver presente, ele deve seguir as regras de retorno das funções e métodos.

    • Caso a palavra chave 'use' esteja presente, deve haver dois pontos logo após o fechamento dos parênteses.

  • Argumentos podem ser separados em múltiplas linhas com cada linha indentada uma vez, deve haver apenas um argumento por linha e o primeiro argumento deve estar na linha seguinte à abertura de parênteses

Classes Anônimas

  • Devem seguir os mesmos princípios e recomendações das closures

  • A chave de abertura deve se encontrar na minha lista que a palavra chave "class", a menos que a lista de interfaces implementadas não resultem em quebra de linha

    • Caso ocorra uma quebra de linha, a chaves de abertura deve se encontrar na linha seguinte à última interface.
Read More

Tags:

Previous Article

Next Article

Wanted to create App for free?

Related Posts

Debug Smarter: How grep Helps Engineers Fix Issues Fast and Stand Out (Part 3)

Debug Smarter: How grep Helps Engineers Fix Issues Fast...

May 13, 2025  0

How to Host a Static Website on Azure Blob Storage

How to Host a Static Website on Azure Blob Storage

May 17, 2025  0

Dica de TI: Concatenação

Dica de TI: Concatenação

May 17, 2025  0