O código e as revisões de código: o que existe em um nome?

Em uma revisão de código, um desenvolvedor precisa olhar para o código de duas perspectivas diferentes:

1. Exatidão: o código está com a lógica correta? Ele trata erros e exceções? Ele checa por parâmetros de input e valores de retorno incorretos? Ele é seguro? E onde o desempenho é importante, ele é eficiente?
2. Manutenção: posso entender esse código suficientemente bem para mantê-lo? Posso alterá-lo eu mesmo com tranquilidade? Ele é legível e consistente? A lógica é muito complexa e os pedaços muito grandes? As unidades já foram testadas e se não, elas podem ser testadas? Esse é o ponto onde um revisor busca por “copiar e colar excessivo” – que em vez disso poderia ser feito utilizando bibliotecas padrão ou recursos de linguagens – aderência a normas de procedimentos e padrões.

É óbvio que usar bons nomes para classes, métodos e variáveis é importante para tornar o código compreensível (se você não pode entendê-lo, não poderá dizer se ele faz o que deveria fazer) e mais fácil de manter. Livros como Clean Code e Code Complete possuem capítulos inteiros sobre nomes corretos. Mas mesmo desenvolvedores bons e experientes têm dificuldade de criar as camadas de abstração corretas e nomes significativos que revelem suas intenções. Isso é ainda mais difícil caso eles estejam trabalhando em um código que eles não conheçam tão bem.

Nomes ruins fazem com que os revisores cometam deslizes ou falsas suposições quanto ao que o código faz. Há nomes defeituosos – nomes preguiçosos, ambíguos ou genéricos que não ajudam o leitor a entender o que está acontecendo com o código. E há os nomes que enganam ou estão simplesmente errados – nomes que costumavam ser corretos, mas não são mais porque a lógica mudou, mas o nome ficou. Você está lendo o código, ele chama postPayment, mas o postPayment já não posta apenas um pagamento agora, ele faz muito mais agora – ou pior, não posta pagamento algum.

Ter foco nos nomes está se tornando mais importante, uma vez que mais código é alterado com uma frequência cada vez maior. O projeto muda, as responsabilidades mudam, muitas vezes crescendo de forma substancial. Código novo é adicionado, outro código é apagado ou movido. O programador que faz as últimas mudanças quer focar apenas no que ele está fazendo, corrigir o código e cair fora, sem olhar para o quadro geral e não percebe que a compreensão do código mudou ou tornou-se menos clara por conta do que ele fez.

Quem quer que revise o código precisa estar atento a esses tipos de problemas.

Mas dar nomes não é apenas tornar mais fácil para mais alguém ler o código e mantê-lo – ou mesmo torná-lo mais fácil para você mesmo ler e alterá-lo quando voltar mais tarde. Como apontou um colega meu, se alguém não consegue sugerir um bom nome para um método ou classe, isso é um sinal de que ele está tendo problemas para compreender o que ele está fazendo. Portanto, na revisão de um código, um nome ruim é mais do que distração ou irritação, é um sinal de que pode haver mais problemas no código, que o desenvolvedor pode não ter entendido o projeto bem o suficiente para fazer a alteração da forma correta, ou que ele não estava prestando atenção suficiente no que ele estava trabalhando e que pode haver outros erros que você, o revisor, precisa encontrar.

Ter foco nos nomes às vezes pode parecer confuso ou exigente demais, mais uma batalha interminável na “guerra dos estilos”, que acabam terminando em luta corporal pela localização dos parênteses ou da indentação. Mas um bom nome é muito mais importante do que simples estética ou padronização. É ter certeza de que o código está funcionando corretamente e que continuará assim.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/02/code-and-code-reviews-whats-in-name.html