Recentemente vi algumas discussões na comunidade dev no Twitter sobre comentários no código e se devou ou não utiliza-lo.

Antes de mais nada, quero reforçar que o conteúdo exposto aqui é uma opinião apenas sobre o assunto e não tem o intuito de expor alguém ou critica-los.

Dito isto, vamos elucidar alguns pontos que, a meu ver, podem trazer um pouco mais de clareza e espero que tire suas conclusões sobre o uso ou não.

Há alguns anos atrás, em 2009 para ser mais exato, o autor Robert C. Martin mais conhecido como Uncle Bob lançou uma série de livros e um deles muito utilizado atualmente, o Clean Code: A Handbook of Agile Software Craftsmanship.

Existe uma tradução para o português do livro de Clean Code, inclusive com o título Código limpo: Habilidades práticas do Agile Software, que diga-se de passagem que é de uma tradução bem fraca.

Mas, voltando ao assunto, nota-se que diversas pessoas (inclusive eu) iniciaram a pensar melhor na legibilidade de seu código com o passar dos ultimos anos

Dentre uma das coisas que pode-se observar, era o quanto custava dar manutenção em projetos com métodos mal escritos ou rotinas que não diziam bem o que estavam fazendo ou para que serviam.

Note que, os problemas são mais densos do que apenas um simples comentário em código. Para quem começou a programar de 2015 pra cá, talvez nunca tenha tido contato com linguagens ou sistemas legados ainda com o paradigma do desenvolvimento procedural.

Nesta época, lembro-me que, até mesmo por padrão de algumas empresas para você fazer um “check-in” (pull request para os dias atuais), você precisava deixar bem claro o que foi alterado no comentário daquele trecho de código.

Tinham extremos até, alguns lugares que trabalhei precisava colocar até detalhes da OS (ordem de serviço) e outras informações, como autor da alteração – muitos sistemas de controle de versão não tinha muito bem implementado estas funcionalidades.

Muitos destes sistemas ainda sobrevivem e estão ativos e pasmem, me falar de Clean Code em sistemas que, se você mexer em uma virgula sem justificativa e der problemas em produção, tu estará no olho da rua no dia seguinte.

Não quer dizer que não devemos tentar implementar boas práticas, não é isto ok? Mas o contexto, a empresa, o projeto fazem o dia-a-dia.

Vejo muitos que ingressam na área e até mesmo influencers, “cagando regra” quase sempre e influenciando mal a turma que está entrando no mercado, porque com certeza irão se deparar com uma barreira parecida.

Agora, tenha em mente que, se o projeto te dá esta liberdade ou você esteja tocando estas decisões, vale a pena abandonar este mantra de comentar código e vou te dizer o porque.

Se seu código não está legível o suficiente, ou se o método não exerça a função que se propõe a fazer é possível que tenha que repensar esta lógica, pois algo não está muito coerente.

Agora se mesmo assim, tiver a necessidade de incluir comentário no código, faça-o sem remorso, afinal a decisão sobre isto cabe a você e sua empresa e não à comunidade.

Se isto vai ficar elegante ou não, lá na frente você e sua empresa que decidirão os custos desta decisão tomada hoje.

Espero ter ajudado a dar luz ai em sua jornada e comente aqui o que acha sobre se quiser. Até a próxima.