Neste artigo apresento dicas para ao desenvolver um software, escrever com boas práticas de código limpo, o que, em geral, significa escrever blocos de código mais legíveis, em alguns contextos, mais fluídos e, bem estruturados.
Existe um engano por parte de pessoas desenvolvedoras em nível júnior, de que o “conceito” de código limpo (do Inglês Clean Code), quase se traduza em escrever menos código. Em minha experiência, além das leituras teóricas, um código limpo é um código que segue boas práticas de programação, padronizações, que o tornam legível para outras pessoas desenvolvedoras, ou mesmo para você mesmo em manutenções futuras.
Guarde este artigo em seus favoritos para revisitá-lo com frequência. Continuamente vou adicionar novas dicas aqui. Siga-me em minhas redes sociais onde avisarei quando novas dicas forem publicadas.
Cada dica apresenta exemplos em algumas linguagens de programação. Algumas dicas podem ser exclusivas de características da própria linguagem. Mas antes das dicas vamos entender por quê escrever código limpo.
Por que escrever código limpo?
A resposta pode não ser óbvia, você deve escrever código limpo por que você não o produz para o computador. Computadores são máquinas entendem instruções binárias, eles não precisam de um código bonito. Eles nem precisam de sua estrutura de arquivos sofisticada ou arquitetura bem projetada. Um interpretador ou um compilador traduz seu trabalho para o código de máquina que não se assemelha em nada com seu belo estado de escrita original.
Então por que você deveria se preocupar? Porque você escreve para pessoas, não para máquinas. As máquinas podem executar o programa com extrema velocidade, enquanto as pessoas precisam de tempo para ler o código linha por linha e interpretar o que ele faz, projetando qual será o resultado.
=> O código bem escrito, o código limpo, facilita esse processo.
Ao focar nas pessoas, você muda seu modelo mental ao analisar seu código, você não questiona mais se “Funciona?” e passa a perguntar “É fácil de entender?”.
O computador entende e interpreta o código mais mal escrito no mundo, desde que contenha as instruções válidas. São as pessoas que precisam de mais tempo para conectar todos os pontos e ver as dependências no código. Você pode ajudá-los (e a você mesmo no futuro) reduzindo a carga cognitiva usando abstrações adequadas, nomenclatura expressiva e estilo consistente.
Mesmo que você ache que isso não se aplica a você, acredito que deveria se importar. Se você conduz um projeto sozinho em uma empresa, outra pessoa pode se juntar a você por causa de demandas mais altas. Se você deixar seu emprego, outro desenvolvedor assumirá seu trabalho. Se você for trabalhar em outro projeto, no futuro precisará ler o seu próprio código quando voltar a ele para dar manutenção.
Agora que você compreende o valor em escrever código limpo, deixe-me mostrar um conjunto não definitivo de boas práticas para escrevê-lo.
Return early
Realize o retorno de suas funções e métodos mais cedo. Do inglês return early, significa executar o return o quanto antes, quando isto evitar estruturas aninhadas ou o uso de else.
Vou começar com um código simples, uma função que chama a exclusão de um item:
function deleteItem(item) {
if (item != null) {
console.log("Deleting item");
item.delete();
return true
}
return false;
}
Não há nada de errado nesta função, porém sua leitura nos obriga a percorrer todas as suas linhas para compreender o que acontece em caso de o item ser igual a nulo. Sua refatoração usando o padrão return early resultaria no seguinte código:
function deleteItem(item) {
if (item == null) return false
console.log("Deleting item");
item.delete();
return true;
}
No primeiro exemplo, além de utilizarmos uma comparação com negação, dificultando a leitura, precisamos mapear o bloco de código que contém a lógica principal da função.
Já no segundo exemplo, simplificamos a leitura da comparação, testando uma igualdade, e retornamos na primeira linha caso a lógica principal não deva ser executada.
Comentários