O conceito de código limpo foi popularizado pelo livro “Clean Code: A Handbook of Agile Software Craftsmanship” de Robert C. Martin. Segundo ele, a redução de duplicação de código, a alta expressividade (código simples e direto) e a criação de abstrações simples no início, são as ações que tornam um código limpo.
De forma a conseguir aplicar esse conceito na prática, neste artigo, serão abordados os seguintes temas:
A primeira regra para funções é que elas devem ser pequenas, algo em torno de 20 linhas no máximo.
As funções devem fazer apenas uma coisa e devem fazê-la bem. Uma forma de saber se uma função faz mais de “uma coisa” é se você extrair outra função dela a partir de seu nome que não seja apenas uma reformulação de sua implementação.
As funções devem fazer ou responder algo, mas não ambos. Sua função ou altera o estado de um objeto ou retorna informações sobre ele. Efetuar as duas tarefas costuma gerar confusão.
A quantidade ideal de parâmetros para uma função é zero. Depois vem um, seguido de dois. Sempre que possível deve evitar três parâmetros.
Esses parâmetros são feios. Passar um booleano para uma função certamente é uma prática horrível, pois ela complica imediatamente a assinatura do método, mostrando explicitamente que a função faz mais de uma coisa. Ela faz uma coisa se o valor for verdadeiro, e outra se for falso. Uma alternativa ao uso dos parâmetros lógicos seria criar duas funções, uma para cada caso.
“Criar um software é como qualquer outro tipo de escrita. Ao escrever um artigo, você primeiro coloca seus pensamentos no papel e depois os organiza de modo que fiquem fáceis de ler. O primeiro rascunho pode ficar desastroso e desorganizado, então você reestrutura e refina até que ele fique como você deseja.”
A primeira regra para as classes é que devem ser pequenas e o tamanho da classe é medida conforme as suas responsabilidades. De acordo com Robert C. Martin, o nome de uma classe deve descrever quais as suas responsabilidades, respeitar o princípio da responsabilidade única e que os nossos sistemas sejam compostos por muitas classes pequenas, e não poucas classes grandes. Cada classe pequena encapsula uma única responsabilidade, possui um único motivo para ser alterada e contribui com poucas outras para obter os comportamentos desejados no sistema.
O autor do Código Limpo afirma que temos que estruturar nossos sistemas de modo que baguncemos o mínimo possível quando os atualizarmos. Num sistema ideal, incorporaríamos novos recursos através da expansão do sistema e não alterando o código existente. Ou seja, precisamos suportar o princípio-chave de projeto de classe, conhecido como Princípio de Aberto-Fechado (OCP).
Segundo Robert C. Martin, o uso adequado de comentários permite compensar nosso fracasso em nos expressar no código. Devemos usá-los porque nem sempre encontramos uma forma de nos expressar sem eles, mas o seu uso não é motivo de comemoração. Então, quando você estiver numa situação na qual precise criar um comentário, pense bem e veja se não há como se expressar através de código em si. De acordo com o autor do Código Limpo, quanto mais antigo um comentário for e quanto mais longe estiver do código o que ele descreve, mais provável será que esteja errado. O motivo é simples. Não é realístico que programadores consigam mantê-los atualizados. O autor afirma também que uma das motivações mais comuns para criar comentários é um mau código. Melhor do que inserir um comentário é limpar o código!
No entanto, certos comentários são necessários ou benéficos, tais como:
Como também existem aqueles que podem ser evitados:
Para que seu código fique bem formatado, você deve escolher uma série de regras simples que governem seu código e, então, aplicá-la de forma consistente. Se estiver trabalhando em equipe, então, todos devem concordar com uma única série de regras de formatação. Atualmente, existem ferramentas automatizadas para ajudar na aplicação dessas regras.
O autor do livro Código Limpo recomenda indentar o código. Segundo ele, a indentação é uma forma de tornar visível a hierarquia dos escopos, indentando as linhas do código-fonte de acordo com sua posição na hierarquia.
Em suma, a clareza na escolha dos nomes para funções, métodos, classes, módulos e variáveis é crucial para a compreensão e manutenção do código. Evitar trocadilhos, dicas falsas e nomes engraçados, enquanto prioriza distinções significativas e pronunciáveis, não apenas facilita a leitura, mas também revela o propósito subjacente de cada elemento. Assim como na escrita de um artigo, onde a organização dos pensamentos resulta em clareza, a estruturação cuidadosa do código torna-o legível e, ao mesmo tempo, robusto.
No próximo artigo, vamos abordar temas como tratamento de erros, testes de unidade e outros aspectos importantes para a busca da excelência no código limpo. Não perca!