O prazo aperta. O atalho parece racional: um if a mais, um nome curto, uma função que “já faz tudo”. O commit passa. A demo funciona. Duas sprints depois, ninguém consegue alterar o desconto sem quebrar o estoque.
Clean Code não é estética. É o custo de ler, mudar e não ter medo. A pressa não elimina esse custo. Ela só transfere a fatura para o futuro, com juros.
O que a pressa realmente compra
No curto prazo, código sujo entrega. Isso é verdadeiro e é o motivo pelo qual o hábito sobrevive. O que some da conversa é a curva: cada atalho aumenta o tempo da próxima mudança. Chega um ponto em que “adicionar um campo” vira arqueologia.
Produtividade que depende de lembrar o contexto na cabeça não escala para o time. Escala só para a pessoa que escreveu — e só enquanto ela lembra. Código limpo reduz essa dependência. Você lê a intenção sem reconstituir a história do incidente de terça.
A regra do escoteiro continua útil porque é pequena: saia do arquivo um pouco melhor do que entrou. Não é refatorar o módulo inteiro. É o nome mentiroso, o parâmetro booleano, o trecho copiado. Limpeza contínua é mais barata do que o projeto de “vamos reescrever no próximo trimestre”.
Nomes são recuperação, não enfeite
Um nome é a primeira interface. d, tmp, data2 obrigam o leitor a abrir o corpo. prazoEmDiasUteis já afirma. Se você precisa de um comentário para explicar o identificador, o identificador perdeu.
Nomes mentirosos custam mais do que nomes vagos. Chamar de list o que é um mapa, chamar de user o que é uma sessão, chamar de save o que também dispara e-mail: o próximo leitor vai errar com confiança. Confiança errada é bug.
Procure nomes pronunciáveis e pesquisáveis. hp no meio do domínio financeiro pode ser “hora padrão” ou “honorário do professor”. Daqui a seis meses você vai buscar a palavra que o negócio usa. Se o código fala outra língua, a busca falha e a regra de negócio fica invisível.
Substantivo para tipo, verbo para ação. Pedido e fecharPedido. Evite prefixos de tipo (strNome, arrItens) salvo quando o time já tem uma convenção rígida — e mesmo aí, o contexto da classe costuma bastar. O nome deve revelar o propósito no lugar em que ele aparece, não o tipo que o compilador já conhece.
Funções pequenas são funções que cabem na cabeça
Função pequena não é dogma de linha. É uma coisa só, no mesmo nível de abstração. processarPagamento que valida cartão, grava banco, emite nota, envia e-mail e atualiza estoque não é uma função. É um roteiro escondido.
Quando todas as linhas estão no mesmo nível — orquestrar, não misturar I/O com regra e com formatação —, a leitura desce como um índice. A função de cima diz o quê. As de baixo dizem como. Se no meio do orquestrador aparece um for de 40 linhas parseando CSV, o nível quebrou.
Parâmetros também denunciam. Zero é o ideal em objeto; um é comum; três já pedem agrupamento. Flag booleana (true para “também notificar”) quase sempre esconde duas funções. O chamador precisa saber um segredo. O corpo vira if (notificar). Extraia.
Efeito colateral silencioso é o primo do nome mentiroso. Uma função getSaldo que também grava auditoria e invalida cache não “pega saldo”. Ela muda o mundo. O leitor que a usa em um relatório paralelo vai se surpreender. Surpresa em código é defeito de desenho.
flowchart TD
A[Prazo aperta] --> B{Atalho agora?}
B -->|Sim| C[Entrega imediata]
C --> D[Próxima mudança mais cara]
D --> E{Ainda dá para ler?}
E -->|Sim| B
E -->|Não| F[Medo de tocar]
F --> G[Retrabalho ou reescrita]
B -->|Não| H[Nome e função claros]
H --> I[Mudança local]
I --> J[Próxima entrega mais barata]
classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
class A,B ouro
class C,D,E,H,I verde
class F,G,J fim
Quando limpar é o trabalho
Há um mito de que qualidade é o que sobra depois da feature. Em código que já dói, a feature é a limpeza. Você não adiciona o novo tipo de desconto no switch de 200 linhas. Você torna o cálculo extensível e aí o desconto entra sem drama.
Isso não autoriza reescrita por vaidade. Autoriza o trabalho mínimo que deixa a próxima alteração local. Extrair a classe que misturava persistência e regra. Quebrar a função que valida e persiste. Renomear o método que diz handle e faz quatro políticas.
Teste é o que torna essa limpeza segura. Sem teste, refatorar é rezar. Com teste, o nome novo e a função menor são mudanças de baixo risco. Se o time não tem teste, o primeiro passo de “código limpo” pode ser o teste que trava o comportamento atual — não o redesign.
| Sintoma | Custo da pressa | Movimento mínimo |
|---|---|---|
| Nome que exige comentário | Leitura lenta, busca inútil | Renomear com a regra de negócio |
| Função de 80 linhas | Medo de editar o meio | Extrair um nível de abstração |
| Flag booleana | Duas políticas no mesmo corpo | Duas funções ou dois tipos |
| Cópia entre arquivos | Bug corrigido em um lugar só | Extração honesta, não “utils” genérico |
| “Não mexo nisso” | Feature vira projeto | Teste de caracterização + corte pequeno |
O que não é clean code
Não é indentar e aplicar linter. Ajuda, mas formatação não revela intenção. Não é comentar o óbvio. Comentário que traduz o if é admissão de que o if está opaco. Comentário que explica por que uma restrição existe — lei, bug antigo, contrato com terceiro — continua valioso.
Também não é transformar tudo em padrão. Uma função de oito linhas claras não precisa virar Strategy. Clean Code bem aplicado reduz cerimônia, não a inventa. O teste é simples: depois da mudança, um colega encontra o ponto certo em menos tempo?
Um exercício na próxima revisão
- Abra um arquivo que o time evita.
- Escolha um identificador que obriga a ler o corpo. Renomeie.
- Extraia um bloco que está em outro nível de abstração.
- Remova uma flag booleana ou documente por que ela ainda existe.
- Escreva, em uma frase, o que a função agora não faz.
O objetivo não é a beleza. É devolver velocidade ao time. Pressa que gera medo não é rapidez. É dívida com vencimento curto.
Os livros da Programming One tratam nome e função pequena como parte do projeto, não como capítulo moral no fim: o código precisa ser lido de novo na semana seguinte.
Leia também: SOLID sem dogma e Design patterns: o catálogo não substitui o problema.
Python One
Do primeiro print à API REST em produção.