Boas práticas Clean Code:

Somos autores do nosso código

Esse é um conceito simples, porém muito importante! Devemos comparar a escrita de um código como a de um livro, em ambos os casos, somos autores, e todo autor tem leitores! Passamos dez vezes mais tempo lendo o código do que escrevendo-o, por tanto, seja um verdadeiro autor e escreva seu código como se fosse uma história de fácil leitura.

Nomes significativos

Você já reparou que no processo de desenvolvimento de um software, damos nomes para praticamente tudo? Variáveis, funções, métodos, parâmetros, classes, objetos, arquivos fonte, diretórios, projetos, branchs do controle de versão e etc.. Muita coisa né?!

Os nomes estão por toda parte, escolher bons nomes leva tempo, mas economiza muito mais!

Use nomes que revelem seu propósito.

Se um nome requer um comentário, então ele não revela seu propósito! {.is-warning}

Devemos escolher nomes que sejam claros e objetivos, que expressam claramente a sua intenção.

Use nomes passíveis de busca

Não abrevie e evite siglas, exceto se todos conhecerem. (Exemplo: API, pt-BR, códigos fiscais, etc.)

Evite números mágicos

Números mágicos são aqueles números aleatórios que de vez em quando você acaba encontrando no código, eles são “mágicos” porquê se assemelham com o truque de um mágico, sendo necessário uma explicação para que sejam entendidos.

Para evitar os números mágicos, sempre que possível utilize constantes para representar esses valores.

Condicionais

Utilize booleanos de forma implícita

<?php

//Ruim
if (in_array(self::GRUPO_ADMINISTRADOR, $gruposAcesso)) {
    return true;
}

return false;

//Bom
return in_array(self::GRUPO_ADMINISTRADOR, $gruposAcesso));

No exemplo acima, estamos verificando se o valor do grupo administrador existe no array $gruposAcesso através da função in_array(), essa função sempre retorna um boolean, sendo assim faz muito mais sentido retornar o valor da função diretamente!

Evite condicionais negativos

//Ruim
function shouldNotProccess() { //Não devo processar
    // ...
}

if (!shouldNotProccess()) { // Devo processar?
    // …
}

//Bom
function shouldProccess() { // Devo processar
    // ...
}

if (!shouldProccess()) { //Não devo processar?
    // …
}

Porquê? porque é mais difícil de ler, simples assim!

Se você tiver um método que checa um condicional negativo e quiser que esse método retorne true quando a condição for verdadeira, você vai ter que utilizar o operador de negação em uma condição que já testa a negação, isso pode acabar confundido um pouco a leitura do código.

Encapsule condicionais

<?php

//Ruim
if ($article->state === 'published') {
   // ...
}

//Bom
if ($article->isPublished()) {
   // ...
}

Dessa maneira você estimula o reaproveitamento e facilita a manutenção do código, se precisar mudar essa condição um dia, você irá mudar em um único local. Outra vantagem é que você acaba evitando possíveis erros de implementação — o programador pode escrever “published” de forma errada, por exemplo — trazendo pra dentro do objeto a responsabilidade de lidar com o condicional.

Comentários

Não comente o óbvio

Não faça comentários irrelevantes, eles só poluem o código…

Não devem explicar o código

Lembre-se que o código deve ser de fácil entendimento e leitura, deve ser comparado como uma história. Por tanto, você não deve fazer um comentário para explicar o código, ele deve ser auto explicativo.

Não use comentários para versionar o código

Utilize ferramentas apropriadas pra isso, se sua intenção é versionar o código, utilize um controle de versão como o Git ou Subversion, por exemplo.

Funções

Dê preferência para funções nativas

Além de limpar o código economizando algumas linhas, as funções nativas são executas mais rápidas.

Funções pequenas!

Você tem uma função que é composta por várias linhas de códigos? Então você tem um problema! Funções com várias linhas são difíceis de serem entendidas e praticamente impossíveis de serem testadas. Outro ponto negativo, é que sua função provavelmente tem mais de uma responsabilidade, o que quebra o conceito de Single responsibility principle do SOLID.

Evite o uso de flags como parâmetro

Porquê? porque o uso de flags indicam que essa função faz mais de uma coisa. Lembre-se, funções devem fazer apenas uma coisa.

Veja o exemplo abaixo:

<?php

//Ruim
function createFile(string $name, bool $temp = false): void
{
    if ($temp) {
        touch('./temp/'.$name);
    } else {
        touch($name);
    }
}


//Bom
function createFile(string $name): void
{
    touch($name);
}

function createTempFile(string $name): void
{
    touch('./temp/'.$name);
}

O Clean code não se limita somente a estes tópicos, sendo um assunto bastante amplo. Para maior aprofundamento, existe um livro chamado "Clean code", que trás estes e muitos outros exemplos.