Comecemos por uma afirmação que poucos entendem ao ver ou escutar pela primeira vez, principalmente estudantes deste fascinante mundo do desenvolvimento.
Programação é uma atividade social.
Em um artigo recente divulgado pela Software.com, foi constatado que desenvolvedores gastam, em média, APENAS, 52 minutos por dia propriamente escrevendo código. Se você já está fazendo as contas, vai notar que durante uma semana, normalmente composta por 40 horas de trabalho, gastamos somente algo próximo de 10% do nosso tempo escrevendo código. Mas o que isso tem haver com programar ser uma atividade social? Bom, todo o restante do tempo estamos imersos em atividades que vão desde reuniões chatas e improdutivas até discussões relacionadas a um bug ou nova feature que está em code review.
Imagine a situação onde dois programadores, João e Maria, estão conversando sobre um problema na aplicação bancária que trabalham:
João: Maria, você viu aquele problema que relacionado aos logs do nosso sistema de registro de transações? Me parece que o lgOut está ignorando o trsVal e o sndId e por isso não estamos conseguindo mapear de onde os valores vêm.
Maria: Claro! Já concatenei esses dois valores com o rcrId e mudei também o fSys pra garantir que vai tudo pro arquivo certo! Já gero o PR!
![what-meme](/blog/1-what.jpg)
Fiquei confuso até mesmo ao escrever esse diálogo 😅. Bom, tente repeti-lo em voz alta e ver como não faz o menor sentido ter uma conversa utilizando esses nomes de variáveis.
Todos os dias passamos por situações conversamos sobre o codigo que trabalhamos com outros desenvolvedores e trabalhar com nomes de variáveis, classes, arquivos e qualquer outra coisa relacionada que sejam pronunciáveis é de muita importância. Imagine como ficaria mais fácil essa conversa utilizando nomes como: logOutput, transactionValue, senderId, receiverId e fileSystem.
Regras para nomear melhor
De acordo com Robert C. Martin (“Uncle Bob” para os intimos), autor do livro Clean Code, mencionado acima, nos devemos seguir algumas regras quando precisarmos nomear alguma coisa.
- Os nomes devem revelar a sua real intenção
- É importante responder as questões sobre por que essa variável/classe/método existe, o que ele faz e como é utilizado. Se você precisa comentar algo, ele não está fazendo o trabalho direito.
- Evite desinformação
- Só crie uma variável chamada
accountList
se você estiver realmente trabalhando com uma lista.
- Só crie uma variável chamada
- Faça distinções significativas
- Criamos mais problemas quando escrevemos código somente para satisfazer o compilador ou interpretador. Como não podemos criar duas variáveis com o mesmo nome, é comum escrever algo como
personA
epersonB
, o que não significa absolutamente nada.
- Criamos mais problemas quando escrevemos código somente para satisfazer o compilador ou interpretador. Como não podemos criar duas variáveis com o mesmo nome, é comum escrever algo como
- Use nomes pronunciáveis
- Evita o problema que ilustrei no inicio deste artigo.
- Use nomes que facilitem a busca
- É muito mais simples buscar por algo como
workDaysPerWeek
que um número 5 solto no código.
- É muito mais simples buscar por algo como
- Evite prefixos/sufixos nas interfaces, se necessário faça apenas na implementação
- Você não quer que seus usuários saibam que estão trabalhando com interfaces ou implementações concretas. Evite os
I
no início ouInterface
no final de suas interfaces, é melhor adicionar algo nos arquivos que implementam as mesmas, como por exemplo o sufixoImpl
.
- Você não quer que seus usuários saibam que estão trabalhando com interfaces ou implementações concretas. Evite os
- Evite mapas mentais
- Claridade é tudo, quem lê seu código não tem que ficar traduzindo mentalmente nomes do código para algo que ele já conheça. Por que precisaria traduzir
p
paraperson
mentalmente para entender o código?
- Claridade é tudo, quem lê seu código não tem que ficar traduzindo mentalmente nomes do código para algo que ele já conheça. Por que precisaria traduzir
- Utilize verbos em funções e substantivos para classes.
- Utilize apenas uma palavra por conceito
retrieve
,fetch
eget
no final das contas significa a mesma coisa, para que usar tudo no mesmo código?
Conclusão
Como podemos ver, nomear algo pode ser uma tarefa muito mais difícil que alguns imaginam, mas ao gastar um pouco de tempo pensando em como nomear da melhor forma você verá que muito desperdício de tempo será evitado no futuro.
Espero que este artigo tenha te ajudado e te trago alguns insights sobre a importância de dar bons nomes em seu código. Caso tenha alguma dúvida, comentário ou feedbacks sobre o artigo, sinta-se a vontade em me mandar uma mensagem.
Obrigado pela leitura e até a próxima! 👋