Uma equipe de desenvolvimento está revisando o código de um novo projeto. Durante a revisão, foi identificado um método com o nome f1() que calcula o valor final de um pedido com base em impostos e descontos aplicados. Além disso, havia uma classe chamada C1 que agrupava funções relacionadas a pagamentos e envio de produtos. A equipe decidiu refatorar os nomes para refletirem com mais clareza a responsabilidade de cada elemento no código. Com base nos princípios de código limpo, assinale a alternativa que reconhece a forma de melhorar a legibilidade desse código:
Questão
Uma equipe de desenvolvimento está revisando o código de um novo projeto. Durante a revisão, foi identificado um método com o nome f1() que calcula o valor final de um pedido com base em impostos e descontos aplicados. Além disso, havia uma classe chamada C1 que agrupava funções relacionadas a pagamentos e envio de produtos. A equipe decidiu refatorar os nomes para refletirem com mais clareza a responsabilidade de cada elemento no código. Com base nos princípios de código limpo, assinale a alternativa que reconhece a forma de melhorar a legibilidade desse código:
Alternativas
a) A equipe poderia manter os nomes curtos, pois códigos mais compactos tendem a ser mais fáceis de digitar e entender rapidamente.
b) A equipe poderia adicionar comentários detalhados explicando a função do método f1() e a estrutura da classe C1, mantendo os nomes atuais.
c) A equipe poderia renomear o método f1() para calcularValorFinalPedido() e a classe C1 para ProcessadorDePagamento, refletindo suas responsabilidades.
d) A equipe poderia remover o método f1() e distribuir sua lógica entre outras funções menores, mesmo que os nomes não representem diretamente suas funcionalidades.
e) A equipe poderia manter os nomes originais e criar um documento separado explicando o que cada método e classe faz no projeto.
Explicação
Pelos princípios de Código Limpo (Clean Code), nomes devem ser intencionais e descritivos, comunicando claramente a responsabilidade de métodos e classes sem depender de comentários ou documentação externa.
- Problema dos nomes f1() e C1
- São nomes “genéricos/criptográficos”, que não indicam propósito.
- Isso obriga quem lê o código a investigar a implementação para entender o que fazem, reduzindo legibilidade e aumentando custo de manutenção.
- Por que comentários ou documentos não resolvem o problema (eliminatórias b e e)
- Comentários e documentação podem ficar desatualizados.
- Em código limpo, a primeira estratégia é tornar o código autoexplicativo com bons nomes; comentários devem ser exceção, não regra.
- Por que manter nomes curtos por serem fáceis de digitar é ruim (eliminatória a)
- Ser curto não é sinônimo de ser claro.
- O critério principal é expressar intenção: um nome mais longo, mas preciso, costuma ser melhor do que um curto e ambíguo.
- Refatorar apenas a estrutura sem nomes claros não atende ao objetivo pedido (eliminatória d)
- Dividir funções pode ser bom, mas a questão pede especificamente melhorar legibilidade via responsabilidade/clareza dos elementos.
- Mesmo com funções menores, se os nomes continuarem não representando a intenção, a legibilidade ainda ficará prejudicada.
- A alternativa correta (c)
- Renomear para algo como calcularValorFinalPedido() torna explícito o que o método faz.
- Renomear para ProcessadorDePagamento (ou nome equivalente ao seu papel real) comunica a responsabilidade da classe.
Alternativa correta: (c).