Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.
Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.
Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.
Tudo é história
Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.
Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).
Lidando com o passado – reconstruindo o histórico perdido
Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:
/* Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */ Issue na qual se encontra documentado o requisito que deu origem ao requisito: http://meusistemadeissues/issue/825 */ class EmissorEmail {É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:
int diasEntreDatas(Date dataInicial, Date dataFinal) { /* Havia um erro no código abaixo que não considerava sábados e domingos, gerando resultados inválidos. Issue: http://seusistemadeversoes/issue/847 Alterado por Henrique Lobo - 1/3/2016 - 14:20 */ }Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.
Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.
Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:
- Use um sistema de issues e o referencie em seus comentários
- Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
- Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada
Lidando com o passado recente
Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:
int soma(int x, int y) { return x + y; /* Acho a versão anterior pura frescura, por isto substituí pela minha alterantiva melhor otimizada e que não usa ifs! Issue: http://www.meusistemadeissues.com/issue/13 Henrique Lobo - 2/2/2012 - 13:13 return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y; */ }Lidando com o futuro (usando lembretes)
Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).
A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.
boolean autenticar(String login, String senha) { /* TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema Henrique Lobo - 12/3/2004 12:00 Issue: http://www.meusistemadeissues.com.br/issues/666 */ if (login == "dede") { return true; } }Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):
Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.
Refatorando comentários?
Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?
De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.
Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.
Não divulgue segredos
Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:
- Credenciais de acesso a serviços ou servidores
- “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
- Críticas ao empregador ou outros membros da equipe
- Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)
Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?
Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.
Boas leituras
Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:
Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman
Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books – (nota de 2023: não recomendo mais este livro, mais detalhes abaixo)
As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.
Concluindo
Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.
Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)
Nota de 2023
Escrevi este texto em 2016. Nesta época eu recomendava o livro “Código Limpo” no capítulo sobre comentários. Se você o leu por minha recomendação, peço desculpas. Acho que este é um dos textos mais nefastos da história de nossa área.
Busque aqui no blog a parte 3 da série “Eu e o Clean Code” na qual analiso mais a fundo este capítulo.