Clean Code #1: a importância dos nomes

Escrever um código para um computador entender é fácil, o difícil é escrever um código que os serem humanos entendam.

Quem nunca suou frio quando recebeu a notícia de que teria que fazer uma alteração em um projeto legado? Quem nunca escreveu um código ruim e depois justificou com "Não tinha muito tempo"? Será que os programadores que desenvolveram aquele projeto legado, pensaram em boas práticas ou apenas foram na onda do “faz funcionar”?

Manter um sistema é mais complicado do que fazer um do zero. Por isso, é importante ter em mente de que a qualidade do código é importante. Os programadores passam mais tempo lendo código ao invés de escrever, logo, devemos deixa-los fáceis de serem compreendidos por outros programadores.

Mas afinal de contas, o que é um código limpo ?

Existem diversas definições legais sobre isso no livro Clean Code, porém, gostaria de deixar aqui a minha definição pessoal baseada na experiência que possuo:

Um código limpo é fácil de ser entendido por expressar bem sua intenção, fazendo o que se propõem e nada mais. Utiliza corretamente os recursos da linguagem e framework no qual foi implementado.

O objetivo deste post é falar sobre um tópico muito específico nesse universo do Clean Code, a importância dos nomes. Nomeamos arquivos, variáveis, classes, métodos e assim por diante. Mas afinal de contas, por que a nomenclatura é tão importante? Vamos a um exemplo:

Quando se lê calc o que lhe vem à mente? O nome dessa função é muito vaga e não expressa a real intenção do que ela faz. E quanto as variáveis x e y, quando se lê seus nomes não se sabe dizer exatamente o que são, com isso, deve-se ler a função toda para compreender seu propósito.

Agora pode-se notar uma melhora na versão refatorada, quando se lê o nome da função já se sabe o que ela faz. E o que se espera de cada variável também ficou muito mais claro: dividendo e divisor.

É muito importante que todos os nomes façam sentido no contexto ao qual são empregados. À seguir temos outro exemplo:

Apenas lendo o código o que se consegue extrair dele? A classe acima deve calcular o valor a ser pago a um programador freelancer. Se olharmos para o nome da classe já vemos um problema ProgrammerFL. Mas afinal, o que esse FL significa? Talvez alguns tenham entendido, talvez outros tenham demorado mais ou não entendido. Mas o fato é, siglas devem ser utilizas quando a equipe toda sabe seu significado ou quando faz parte da regra de negócio, por exemplo, tabela periódica, etc.

Outro problema são os atributos h e v. Quando são lidos, não se pode afirmar com certeza o que são. E finalmente o método pay, o qual diz apenas "pagar", porém, na prática apenas calcula o valor a ser pago. O método diz uma coisa e faz outra isso é um problema grave.

Após refatorar a classe, pode-se notar que ela ficou muito mais expressiva. Não há siglas para deixar o leitor em dúvida, o nome da classe expressa o que ela faz. Os atributos agora são claros, horas trabalhadas e valor da hora. E o método nos diz que calcula o valor total do trabalho e realmente faz isso.

Algumas dicas para escolher bem os nomes

Use nomes de fácil pronuncia:

Use substantivos em nomes de classes: Ex: Address, Customer, Programmer.

Use verbos em nomes de métodos: Ex: playGuitar, addItem, removeFirst.

Deixe explícito caso use algum design pattern, exemplo, CalculatorStrategy, CustomerFactory.

Conclusão

Nomear as coisas de forma correta é mais complicado do que parece, porém, deve ser algo que todo desenvolvedor deve ter em mente. É muito importante pensar bem nos nomes para que outros desenvolvedores consigam entender sua lógica. Lembre-se sempre, escrevemos códigos para os outros não para nós mesmos.

Caso tenha gostado do assunto, saiba mais lendo a obra completa de Robert C. Martin (Uncle Bob) Clean Code, há um capítulo inteiro falando apenas sobre esse assunto no qual essa publicação se baseou.