Por que escrever código legível?
Segundo Robert C. Martin, em Clean Code, um programador passa 10 vezes mais tempo lendo código do que escrevendo. Isso significa que a facilidade de leitura e entendimento de um código terá impacto direto na produtividade do time.
Toda vez que uma alteração precisa ser feita, um código confuso demanda grande tempo de leitura e entendimento. No momento em que o tal código foi escrito, tanto a necessidade de negócio quanto a lógica que resolviam aquele problema estavam “frescas”, eram claras. Porém, em algumas semanas, após tratar outras diversas demandas, isso tudo já não está mais na sua cabeça. Ou seja, você mesmo vai precisar parar e entender o seu próprio código. E imagine uma outra pessoa tentando entender aquilo, talvez sem nenhum contexto, sem suporte…
Mas o que é um código legível?
Fugindo um pouco do pensamento meramente técnico, um código legível é aquele que, levando em conta a sua complexidade, pode ser compreendido o mais rápido possível. Ele é semântico, traduz a operação de negócio que realiza, buscando — a cada linha — explicitar tudo que está fazendo. Além disso, ele é tecnicamente elegante e organizado. Escrever código legível não é algo fácil ou automático, mas sim uma habilidade que é trabalhada ao longo do tempo.
Existem algumas técnicas que podem ser utilizadas para tornar um código mais limpo, organizado e legível. Abaixo vão algumas dicas básicas:
- Utilize nomes que realmente expressem o seu conteúdo. Seja uma variável, uma classe, um método, um parâmetro, um arquivo. Vale a pena pensar bem nos nomes, pois vai economizar tempo no médio e longo prazo. É muito melhor utilizar um nome mais longo porém mais significativo;
- Nomes de métodos, especialmente, devem descrever efetivamente seu comportamento. Melhor ainda se puderem estar associados a operações de negócios, por exemplo faturarPedido;
- Métodos devem ser o mais curtos possíveis, e devem executar apenas uma tarefa. Aqui, deve-se pensar sempre em refatorar: você pode começar com um método mais procedural, que executa todas as operações necessárias, e depois ir dividindo em diversos métodos menores, cada um com apenas uma ação e com seu nome que deixa muito claro o que ele faz;
- Comentários, normalmente, não são uma boa ideia. Se você sentir necessidade de explicar seu código por meiode um comentário, é porque ele está pouco claro. Tente aplicar as demais dicas e deixá-lo mais limpo e legível. Uma ideia interessante é, ao invés de adicionar um comentário, colocar algum tipo de log, explicitando ainda mais a ação, e utilizando dados que tornem esse log significativo ao precisar fazer um troubleshooting;
- Procure usar uma padronização para nomes. Por exemplo, qual a diferença entre métodos com os nomes fetchDeliveries, getCustomer e retrievePayment? Todos buscam dados? Se todos eles executam a mesma operação, devem ter o mesmo nome, acompanhados do item que eles trazem, como retrieveOrder, por exemplo, estendendo essa padronização por toda a aplicação.
Um código mal escrito, ou feito com pressa, sempre cobra essa “economia de tempo” lá na frente. Um dos valores do manifesto ágil é ‘responder a mudanças mais que seguir um plano’. Com código limpo e legível é muito mais fácil alterar ou evoluir funcionalidades e entregar valor. Vale a pena!
Grande parte dessas idéias são exploradas em mais detalhes no livro citado logo no começo do artigo: Clean Code: A Handbook of Agile Software Craftsmanship.
Leitura mais que recomendada.
- -
Autor
Daniel Augusto Bonaldo — Software Developer
