4 Dicas para Escrever um Código Mais Limpo
Para todos os desenvolvedores que querem se tornar cada vez melhores
Um código limpo pode ser definido como um código facilmente compreensível por terceiros e também pelo próprio autor. O termo facilmente compreensível está relacionado a um código com poucas ambiguidades e que o objetivo da tarefa a ser realizada está claro.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand - Martin Fowler.
Mesmo que um projeto esteja disponível para os usuários, nós nunca paramos de mantê-lo. Sempre precisamos modificar seu comportamento, seja adicionando ou removendo funcionalidades. Um projeto com o código sujo impacta diretamente nessas modificações, pois afeta a produtividade dos desenvolvedores uma vez que fica cada vez mais complicado entender onde inserir ou alterar o código — sem falar no receio de quebrar o que já funciona em produção.
Por isso, essas dicas são um início de direcionamento na busca pela melhora da escrita de código. Em seu livro “Clean Code: A Handbook of Agile Software Craftsmanship”, Robert C. Martin, mais conhecido como Uncle Bob, traz e explica todos os princípios requeridos para essa arte. Em suma, resumirei 4 pontos do livro que já farão uma diferença significativa na escrita do seu código.
1. Nomes são muito importantes
Não só nome de variável, mas qualquer nome: pastas, arquivos, funções, classes, etc. Damos nomes a coisas o tempo todo! Quão importante é dar um bom nome a uma foto que você gosta? Ou ao documento que você precisa enviar em um e-mail importante? Arrisco dizer que nomes são o core de um programa bem escrito.
Trechos de código com nomes de variável, funções ou nomes de classes que tem pouco a ver com o contexto, ou que passam a ideia errada dificultam todo o processo de leitura e entendimento do código. Um nome deve passar uma ideia central e é preferível que ele seja longo a ser ambíguo ou impreciso.
No exemplo abaixo, desejamos que uma função receba um vetor e troque um elemento na posição A pelo elemento na posição B. Ao invés de:
Prefira:
O segundo trecho de código é bem melhor, não é mesmo? Parece mais entendível. No primeiro exemplo, o nome da função new_vector não remete a uma troca, e precisamos ficar um tempo a mais lendo o código até entender seu propósito.
No momento pode parecer bobagem, mas quando você precisar mexer nesse código novamente, qual seria o mais fácil de lembrar e entender o contexto? Em qual deles você precisaria ler menos vezes? E se o código do seu projeto tivesse várias partes escritas como o primeiro exemplo?
2. Deixe seu código mais limpo do que você o encontrou
Código tende a ficar velho. O que hoje não é um débito técnico, pode se tornar um amanhã. Portanto, tenha o hábito de sempre deixar o código um pouco melhor do que você encontrou — obviamente isso não quer dizer que você precisa refatorar todo o código. Você ficará surpreso em quanto isso ajudará na qualidade do código e produtividade à longo prazo.
3. Faça funções curtas e que façam só uma coisa
Quem nunca suspirou fundo ao se deparar com uma função gigante de 50 linhas? 🙂 É realmente muito oneroso e confuso ler funções grandes. Funções que fazem operações em bancos de dados, leem de uma determinada fonte, efetuam determinada operação, enviam dados para outras funções… uma só função acaba tendo muitas responsabilidades e portanto, fica difícil de entendê-las e manutencioná-las.
Funções menores nos ajudam a entender rapidamente o que está acontecendo e onde devemos interferir, caso necessário. Ao invés de:
Prefira:
Claro que o código não está completo, mas a ideia que quero passar aqui é o exemplo de funções que, dependendo dos argumentos de entrada, fazem operações ou tem resultados diferentes. Esse comportamento é um ponto muito propício a falhas e bugs.
Neste exemplo, é preferível que a função faça apenas uma coisa e que o controle do ato de deploy possa ser responsabilidade de outro componente.
4. Ao invés de escrever comentários, reescreva seu código
O Uncle Bob é bem incisivo nesse princípio, ele inclusive afirma que comentários mentem. Se pararmos para pensar, faz muito sentido!
O desenvolvedor pode indicar através de um comentário que seu código faz X, mas conforme o tempo passa e novas adições ao código surgem, os comentários tendem a ser esquecidos. O comentário continuará dizendo que o código faz X, porém o código está fazendo Y. Nesses casos, o comentário vai atrapalhar muito mais do que ajudar.
Dessa forma, é preferível que o código esteja bem escrito e fale por si só, pois afinal, é através dele que iremos de fato descobrir o que o sistema está fazendo. Veja os comentários do exemplo a seguir de um código meu bem antigo, onde eu estava aprendendo a usar containers em C++:
Este é um exemplo que ilustra o mau uso de comentários. Nós podemos perceber que os comentários são pouquíssimo instrutivos ou até mesmo óbvios, pois não ajudam no entendimento do propósito do código e até mesmo polui sua leitura. Eu tive que reler várias vezes para entender que ele apenas lia nomes e idades e os armazenava na estrutura de dados, para imprimi-los ao final do programa.
Vale destacar que há situações em que comentários são muito bem-vindos, principalmente quando isso irá nortear o desenvolvedor de alguma forma que pode não ficar clara. Entretanto, devemos ter a cautela de sempre cuidar desse tipo de comentário como se fosse um trecho de código.
Conclusão
Gosto sempre de citar uma afirmação de Michael Feathers: “Um código limpo sempre parece que foi escrito por alguém que se importava”, pois no fim das contas, um código limpo é um código feito com cuidado. Isso é essencial quando se trata de manter um projeto em produção com qualidade à longo prazo, e impacta diretamente na produtividade dos desenvolvedores.
Vale ressaltar que essa é uma habilidade que requer melhoria contínua: é como pintar um quadro ou escrever um texto, dificilmente fica bom de primeira. Portanto, temos que ser pacientes mesmo 😃 Espero que o post seja útil e que com essas dicas você já tenha um direcionamento que ajude a melhorar significativamente sua forma de programar!
Referências
Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin. Editora AltaBooks, 2011.
