Um dos grandes diferenciais que eu vejo quando eu analiso o teste de uma pessoa candidata à uma vaga é: o tempo que ela dedicou para fazer um código de qualidade além do que era exigido nos requisitos. Fazer os requisitos é o mínimo que se espera receber (claro, temos exceções para pessoas de perfil júnior), então se você quer se destacar, vá além!

Mas, temos que concordar que a expressão "qualidade de código" é um pouco subjetiva, né? O que pode ser qualidade para mim, pode não ser para você.

Para dirimir essa dúvida, existem padrões, boas práticas e ferramentas que nos dão um norte para onde devemos seguir se queremos aumentar a barra no quesito qualidade. Vamos conhecer alguns aqui.

PSR

Eu já citei no primeiro episódio dessa série de artigos sobre o PHP, as PSR's, e qual a importância delas para uma aplicação de boas práticas e padronização de código.

Entrando um pouquinho mais no detalhe, hoje em dia temos 13 PSR's aprovadas e ativas. Tem PSR focada na padronização do autoloading de classes, outras com o intuito de padronizar requisições HTTP, etc.

Meu foco aqui, serão as mais conhecidas e básicas PSR's: as de coding style.

Padronização de codificação ajuda, e muito, a legibilidade do código e, consequente, a manutenção por diversas pessoas sem perder a qualidade.

PSR-1: Basic Coding Style

Essa seção trás o que deve ser considerado como elementos padrão de codificação para garantir um mínimo de interoperabilidade entre códigos que mais de 1 pessoa mantém.

Como o próprio nome dessa série propõe, os artigos são apenas guias para orientar você nos seus estudos. Então, não vou ficar replicando o que pode ser encontrado de forma fácil na página da própria PSR-1. Mas, apenas para citar alguns exemplos:

• Nomes de classes devem ser declarados no formato studly caps: UmExemplo;
• Nomes de métodos devem se declarados no formato camel case: umExemplo;
• Constante deve ser em caixa alta com underscore na separação: UM_EXEMPLO;
• etc...

PSR-12: Extended Coding Style

Essa aqui veio para substituir a PSR-2 que foi depreciada. E, ainda, estende a padronização definida na PSR-1.

A ideia central dessa PSR é prover um meio para que ferramentas de coding style possam implementar essas regras, facilitando a vida da pessoa que está desenvolvendo o código. Algumas dessas regras:

• Deve seguir todas as regras da PSR-1;
• Usar 4 espaços para identação, não usar TAB;
• Chaves em classes e métodos devem ser abertas na linha de baixo;
• etc...

Você deve estar pensando nesse exato momento: caramba, vou ter que decorar tudo isso na hora de codar? É aí que você se engana, jovem padawan! Existem ferramentas que nos auxiliam nesse processo. Afinal, automatização é o caminho (this is the way).

(duas referências ao universo de Star Wars em um mesmo parágrafo é para poucos 😁)

PHP Code Sniffer

Como o próprio nome já diz, essa ferramenta faz o papel de "farejador" de violações de padrões de código definidos previamente.

Como você pode ver no repositório da ferramenta, na hora que você roda o comando, você define qual padronização seguir.

$ phpcs --standard=PSR12 /path/to/code-directory

Nesse caso está aplicando a PSR-12 para o arquivo especificado. Após rodar o comando, ele nos retornará uma espécie de relatório com as violações encontradas.

Existe, ainda, uma maneira mais fácil de fazer isso: o bom e velho plugin do VS Code chamado phpcs.

Com esse plugin, enquanto você está codando, se você violar o padrão definido (nesse caso aqui você define nas configurações do plugin), o próprio VS Code já dá um highlight com aquela linha vermelha avisando que algo está errado.

O lado ruim disso é que se você pegar um código legado o VS Code vai ficar parecendo a bandeira da China de tão vermelho que estará.

Outro plugin que você pode usar no VS Code é o php-cs-fixer. A diferença entre esse e o anterior é que esse aqui não apenas identifica a quebra de padrão, como também corrige (por isso tem fixer no nome).

Use esse plugin com moderação, pois se você pegar aquela classe legada, com diversos erros de identação, espaçamentos errados, e diversas outras quebras de padrão, e der um fixer... quando você for mandar suas alterações para um pull-request e as outras pessoas do seu time forem avaliar seu código, suas alterações irão ficar perdidas no meio de tanta correção de padrão e ficará inviável revisar o seu código e o impacto que ele trará, seja positivo ou negativo. O ideal é ter uma correção de padrão parcial e, se possível, um pull-request específico para isso.

Para não me alongar muito com esse post, vou listar abaixo mais algumas ferramentas comumente usadas com o intuito de manter um qualidade de código na aplicação:

• PHPStan: É uma ferramenta open source de análise estática do PHP bastante popular. Sua principal funcionalidade é encontrar erros em seu código sem executá-los para isso.
• PHP Mess Detector: Como o próprio nome diz, é um detector de bagunça. Dentre as principais funcionalidades está identficar possíveis bugs, códigos sem qualidade, verificar complexidade e legibilidade do código.
• Psalm: Muito similar ao PHPStan, Psalm é uma ferramenta open source de análise estática que tem como premissa corrigir possível bugs através da execução do seu binário.

Conhece alguma outra ferramenta que faz algo a mais que as listas acima? Comenta aí! :)