Qual alternativa abaixo apresenta uma boa prática correta de “*clean code*” associada a comentários?

Alternativa (C) - Não fazer comentários redundantes que dizem exatamente o que o código está fazendo, pois são ruins e desnecessários.

Introdução

A prática de "Clean Code" (Código Limpo) é fundamental no desenvolvimento de software para garantir que o código seja fácil de ler, entender, manter e estender. Dentro desse conjunto de boas práticas, a utilização de comentários é um tópico frequentemente debatido, pois, embora possam parecer úteis, muitas vezes acabam se tornando um obstáculo para a clareza e a manutenção do código. A questão aborda uma das diretrizes mais importantes sobre o uso de comentários no contexto de código limpo.

Desenvolvimento

No paradigma de Clean Code, a filosofia central é que o próprio código deve ser tão expressivo e autoexplicativo quanto possível. Isso significa que nomes de variáveis, funções, classes e a estrutura geral do código devem comunicar sua intenção e funcionalidade sem a necessidade de explicações adicionais. Comentários são frequentemente vistos como um "cheiro" (code smell), um sinal de que o código pode não ser tão claro quanto deveria.

Quando comentários são absolutamente necessários, eles devem servir a propósitos específicos e não óbvios pelo código em si. Bons comentários explicam por que uma decisão foi tomada ou qual é a intenção por trás de uma implementação que pode parecer estranha, em vez de simplesmente repetir o que o código está fazendo. Comentários redundantes são particularmente prejudiciais, pois adicionam ruído visual, ficam desatualizados facilmente e não agregam valor real, desviando a atenção do leitor sem oferecer uma nova perspectiva.

Análise

Vamos analisar cada alternativa à luz dos princípios de Clean Code sobre comentários:

| Alternativa | Análise | | :---------- | :------ | | (A) É melhor ter comentários no código, mesmo que ruins, do que gastar tempo refatorando o código. | Incorreta. Comentários ruins (desatualizados, imprecisos, misleading) são piores do que a ausência de comentários, pois podem enganar o desenvolvedor e levar a erros. Refatorar o código para torná-lo claro é sempre a melhor prática, pois garante que a verdade esteja no código e não em um comentário propenso a obsolescência. | | (B) Uma forma inteligente de fazer um comentário é usar a própria linguagem de programação para isso. | Incorreta. Esta alternativa é ambígua, mas se a interpretação é que se deve usar o código (linguagem de programação) para ser autoexplicativo, então o comentário em si se torna desnecessário. Se a interpretação é usar a sintaxe de comentário da linguagem para fazer "bons comentários", ela não especifica o critério de "bom". Em Clean Code, a meta é que a linguagem do código por si só seja o "comentário", ou seja, o código deve ser legível. | | (C) Não fazer comentários redundantes que dizem exatamente o que o código está fazendo, pois são ruins e desnecessários. | Correta. Esta é uma premissa fundamental de Clean Code. Se o código já é claro, um comentário que apenas descreve o que ele faz é redundante. Por exemplo, int saldo = valorCredito - valorDebito; // Calcula o saldo da conta. O comentário é inútil, pois a linha de código já é autoexplicativa. Comentários redundantes poluem o código e exigem manutenção adicional. | | (D) É melhor ter comentários imprecisos do que nenhum. | Incorreta. Comentários imprecisos são extremamente perigosos. Eles fornecem informações falsas ou enganosas, o que pode levar a decisões de design erradas, bugs difíceis de rastrear e frustração. É preferível não ter comentário algum do que ter um que induza ao erro. | | (E) Quanto mais longo o comentário, melhor. | Incorreta. A qualidade de um comentário não está ligada ao seu comprimento. Comentários devem ser concisos e diretos, transmitindo a informação essencial sem prolixidade. Comentários excessivamente longos podem indicar um código complexo que precisa ser refatorado ou que o comentário está explicando algo que deveria ser evidente pelo código. |

Conclusão

Em resumo, a filosofia de Clean Code prioriza a clareza do código sobre a proliferação de comentários. Comentários devem ser uma medida de último recurso, utilizados estrategicamente para explicar a intenção por trás de um trecho de código não óbvio ou para fornecer informações cruciais que o próprio código não pode expressar. Evitar comentários redundantes é uma prática essencial para manter o código limpo, legível e fácil de manter, pois eles adicionam ruído e se tornam um passivo de manutenção. O objetivo é escrever código que fale por si mesmo, minimizando a necessidade de explicações externas.

Alternativa (C).