Voce ja abriu um codigo que escreveu ha tres meses e nao entendeu nada? Isso acontece ate com devs experientes. Clean code nao e sobre ser perfeito, e sobre escrever codigo que outro ser humano (ou voce no futuro) consiga ler sem reclamar. Estas 10 praticas de clean code sao o caminho mais curto para um codigo que da menos trabalho de manter.
1. Nomes que revelam a intencao
O nome de uma variavel, funcao ou classe deve responder: por que ela existe, o que faz e como e usada. Se precisar de um comentario para explicar o que um nome significa, o nome esta errado.
Exemplo concreto: Troque int d; // dias desde a modificacao por int diasDesdeUltimaModificacao. O nome maior ocupa espaco, mas evita que voce abra o codigo e precise decifrar o que d significa. O custo de ler um nome descritivo e menor que o custo de interpretar um nome obscuro.
2. Funcoes pequenas e com uma unica responsabilidade
Uma funcao deve fazer exatamente uma coisa, fazer bem e nao ter efeitos colaterais escondidos. Se voce precisa de um comentario para explicar o que uma funcao faz, divida-a.
Criterio pratico: Uma funcao que precisa de mais de 20 linhas ou tem mais de 3 niveis de indentacao provavelmente faz mais de uma coisa. Extraia blocos internos em funcoes separadas. No final, o codigo fica mais facil de testar e de alterar sem quebrar outras partes.
3. Elimine comentarios que repetem o obvio
Comentarios que apenas traduzem o codigo para portugues sao ruido. // incrementa o contador ao lado de contador++ nao agrega nada. Use comentarios apenas para explicar o "por que" de uma decisao nao obvia, nunca o "o que".
Ressalva: Comentarios de licenca, TODO ou alertas de seguranca sao excecoes. Mas, se o codigo depende de um comentario para ser entendido, o codigo precisa ser refatorado, nao comentado.
4. Trate erros, nao os ignore
Codigo que engole excecoes com catch vazio ou retorna null sem tratamento e uma bomba-relogio. Cada erro ignorado hoje sera um bug dificil de rastrear amanha.
Exemplo: Em vez de try { ... } catch (Exception e) {}, registre o erro, exiba uma mensagem amigavel ou propague a excecao para quem possa tratar. Usar excecoes especificas (nao Exception generica) tambem ajuda a identificar o problema sem abrir o codigo.
5. Mantenha a consistencia no estilo de codigo
Se o projeto usa camelCase para variaveis, nao misture com snake_case. Se as chaves abrem na mesma linha, mantenha assim. Um guia de estilo (ou um formatador automatico como Prettier ou ESLint) elimina discussoes e padroniza a leitura.
Dado concreto: Times que usam formatacao automatica gastam em media 20% menos tempo em code review discutindo estilo, segundo levantamentos informais de comunidades de desenvolvimento. O foco vai para a logica, nao para a indentacao.
6. Prefira objetos pequenos e coesos
Uma classe com mais de 200 linhas ou que faz coisas nao relacionadas (como ler arquivo e enviar email) viola o principio da responsabilidade unica. Divida em classes menores, cada uma com um proposito claro.
Criterio: Se voce nao consegue dar um nome descritivo para a classe em menos de 30 segundos, ela provavelmente tem responsabilidades demais. Refatore ate que o nome da classe seja suficiente para entender o que ela faz.
7. Evite parametros booleanos em funcoes
Parametros booleanos geralmente indicam que a funcao faz duas coisas diferentes: uma quando true, outra quando false. Isso quebra a regra da responsabilidade unica.
Exemplo: processarPedido(pedido, true) nao revela o que o true significa. Crie duas funcoes: processarPedidoNormal(pedido) e processarPedidoUrgente(pedido). O codigo fica mais explicito e mais facil de testar.
8. Nao repita logica (DRY)
Codigo duplicado e a principal causa de bugs de manutencao. Quando uma regra de negocio muda, voce precisa lembrar de alterar em todos os lugares que copiaram a mesma logica.
Ressalva: DRY nao significa eliminar qualquer repeticao textual. As vezes duas funcoes tem o mesmo codigo mas representam conceitos diferentes. Nesse caso, a duplicacao e aceitavel se a extracao criar um acoplamento artificial. Use o bom senso.
9. Escreva testes que validem comportamento, nao implementacao
Testes que verificam detalhes internos (como chamadas de metodos privados) quebram a cada refatoracao. Prefira testar a saida esperada para determinadas entradas, sem depender de como a funcao implementa o resultado.
Criterio: Se voce precisa mudar os testes toda vez que refatora o codigo interno, os testes estao muito acoplados. Um bom teste de unidade deve permitir que voce reescreva a funcao por completo e ele continue passando, desde que o comportamento externo nao mude.
10. Refatore em pequenos passos, sem pressa
Nao tente limpar um codigo inteiro de uma vez. Isso introduz bugs e frustra o time. Refatore em ciclos curtos: escolha uma funcao, aplique uma ou duas praticas, rode os testes e siga.
Exemplo pratico: Pegue uma classe de 300 linhas. Extraia um metodo de 10 linhas. Rode os testes. Se passou, commit. No dia seguinte, extraia outro. Em uma semana, a classe estara mais limpa sem ter parado o desenvolvimento.
Perguntas Frequentes sobre Clean Code
O que e clean code?
Clean code e codigo legivel, simples e de facil manutencao. Segue principios como nomes descritivos, funcoes curtas, tratamento de erros e ausencia de duplicacao desnecessaria. O foco e na comunicacao com outros desenvolvedores, nao apenas com o computador.
Clean code e coisa de iniciante?
Nao. Desenvolvedores experientes tambem escrevem codigo sujo quando estao sob pressao. Clean code e uma disciplina que se pratica constantemente, independentemente do nivel. O diferencial e reconhecer quando o codigo precisa ser limpo e ter a coragem de refatorar.
Qual a diferenca entre clean code e SOLID?
Clean code e um conjunto amplo de praticas de legibilidade e manutencao. SOLID sao cinco principios especificos de design orientado a objetos (Responsabilidade Unica, Aberto/Fechado, Substituicao de Liskov, Segregacao de Interfaces, Inversao de Dependencia). Ambos se complementam: SOLID ajuda a estruturar a arquitetura, clean code cuida da expressao no nivel de funcoes e classes.
Devo aplicar clean code em projetos legados?
Sim, mas com cuidado. Comece pelo codigo que voce precisa alterar com frequencia. Aplique a regra do escoteiro: deixe o codigo um pouco mais limpo do que encontrou. Refatorar um projeto legado inteiro de uma vez e arriscado e normalmente nao e prioridade de negocios.
Clean code deixa o codigo mais lento?
Em geral, nao. A maioria das praticas de clean code (nomes descritivos, funcoes pequenas) nao afeta performance. Em raros casos, a extracao de funcoes pode adicionar overhead de chamada, mas compiladores modernos otimizam isso. Priorize legibilidade; se a performance for critica, meca antes de presumir que o clean code e o culpado.
Como convencer o time a adotar clean code?
Comece com exemplos praticos: mostre como uma funcao refatorada ficou mais facil de testar e de entender. Proponha um coding dojo de 30 minutos por semana para refatorar um trecho juntos. Nao imponha regras de cima para baixo; mostre o valor na pratica. Quando o time sentir que o codigo da menos trabalho, a adocao vem naturalmente.