Programmers are taught to comment their code: good code has lots of comments. Unfortunately, they are never taught why code needs comments: bad code requires lots of comments.
A tradução seria algo como:
Programadores são ensinados a comentar seus códigos: código bom tem um monte de comentários. Infelizmente, eles nunca são ensinados porque código precisa de comentários: código ruim requer um monte de comentários.
Lembrei deste capítulo esses dias quando minha professora de engenharia de software afirmava que código bom é código comentado.
Um código bem escrito fala por si só, comentários nesse caso poderiam ser encarados até como duplicação de informação (DRY, don't repeat yourself).
Mas o que eu chamo de código bem escrito?
Nem sempre o algoritmo que resolve uma solução com menos linhas, ou até mesmo um que obtém um melhor desempenho, é a melhor solução para um determinado problema. Programação é mais do que bons algoritmos, trata também de legibilidade, utilização de padrões, código flexível e reutilizável, entre outros.
Esse algoritmo com menos linhas, pode ser algo não reutilizável em situações similares. Ou um código que, por utilizar uma solução não convencional (gambiarra), pode não ser tão legível para outro programador, ou para você mesmo daqui uns meses.
Eu tento sempre quando estou programando pensar em soluções simples. Na maioria das vezes eu penso em como eu faria se fosse feito manualmente e então implemento algo que siga o mesmo caminho, utilizando os benefícios que a linguagem e o framework me proporcionam.
Por exemplo, vamos dizer que eu tenho uma pilha de tijolos de lego em meu sistema, e tenho que desenvolver um processo nele onde ele encontre uma quantidade determinada de tijolos de uma mesma cor. Por exemplo, eu quero que ele busque 5 tijolos vermelhos.
Se eu fosse fazer manualmente, eu correria os tijolos com os olhos (utilizando a mão se necessário) verificando a cor de cada um e iria separando os vermelhos até obter a quantidade esperada. Se eu não encontrasse a quantidade necessária, sabendo que lá é o único lugar para conseguir os tijolos, alertaria a quem me pediu.
Para implementar o sistema eu faria da mesma forma. Solicitaria a cor e a quantidade desejada. Correria um laço pelos tijolos disponíveis peguntando a cada um deles qual é sua cor. Logo, a classe tijolo teria de ter um método que diz sua cor. Se encontrasse quantos eu precisasse eu retornaria a quem me pediu. Se ao chegar ao final eu não tivesse encontrado, retornaria um erro, ou exceção (dependendo de quão comum fosse essa escassez dos tijolos - se fosse algo possível de acontecer, erro, se fosse algo que não deveria acontecer, exceção).
Mas, e se eu descobrisse que os tijolos vermelhos são mais leves dos que os demais e que, se eu desse uma pancada na mesa, os tijolos vermelhos seriam os únicos que pulariam acima de 20 cm de altura? Iria eu utilizar isso para desenvolver uma técnica mais rápida de conseguir os tijolos vermelhos?
Provavelmente não. Ainda assim eu optaria pela primeira solução, por diversos motivos:
- Ela é a solução mais esperada, se alguém ler esse código com certeza vai entender do que se trata, mesmo ele não estando comentado.
- E se um dia os tijolos azuis ficarem mais leves ou tão leves quanto os vermelhos?
- A primeira solução funciona para qualquer tipo de tijolo, independente da cor.
- A primeira solução, por ser simples, é mais flexível e extensível. A segunda opção, por tratar uma situação muito específica, será mais difícil de expandir ou alterar quando os usuários solicitarem. E acreditem, todo código nasce para ser expandido ou alterado futuramente. Se ainda não solicitaram isso, irão.
Precisamos sempre avaliar o código que estamos criando por diversos fatores diferentes. Muitas vezes uma melhor legibilidade vale mais do que uma pequena melhora de desempenho ou um código menor. É necessário avaliar quais são as reais prioridades no projeto.
Se por algum motivo você tiver que optar por uma solução não convencional, aí seria indicado deixar um comentário. Se você perceber que seu código está ficando com muitos comentários, o melhor é reavaliar se seu programa está indo na direção correta.
Uma programação de forma simples pode lhe trazer diversos benefícios, portanto fique sempre atento ao método como você está programando.
Um comentário:
Muito bom...!
Abraço
Postar um comentário