Se você abriu o livro Clean Code, leu as primeiras páginas e ficou com a sensação de “ok, mas o que EU faço com isso na prática?”, esse artigo é para você. O capítulo 1 do livro não te dá uma checklist — ele te dá seis definições diferentes de código limpo, vindas de seis pessoas diferentes. É rico, mas também é fácil se perder. Vou organizar isso de um jeito que dá pra usar como bússola.
Primeiro: o que é um código, afinal
Antes de definir código limpo, vale voltar ao básico: por que a gente escreve código? Uncle Bob define isso como a forma que usamos para expressar nossos requisitos. No meu caso, trabalhando com sistemas embarcados, se eu aperto um botão eu quero que acenda um LED, ou que um motor gire. Já numa aplicação diferente — eu já escrevi programas para puxar dados de mercado financeiro e ajudar a decidir qual ação comprar —, o requisito era outro: acessar uma base de dados, calcular indicadores, tomar uma decisão melhor. Código é a tradução de uma necessidade em instruções que a máquina executa. Simples assim.
A analogia do código ruim
O livro compara um código ruim a um lamaçal cheio de arbustos e armadilhas. É uma boa imagem, mas eu prefiro outra: um código ruim é como estar num barco no meio do mar, sem bússola, sem mapa, cercado de corais. Se você não sabe por onde navegar, você está perdido — e cada movimento errado (cada linha que você mexe sem entender o resto) tem chance de bater num coral e afundar o barco. Quanto mais você mexe num código ruim sem entender a estrutura, mais problemas aparecem e mais difícil fica seguir em frente.
Esse é o ponto central: código ruim não é feio esteticamente, ele é perigoso de mexer.
O balanço que todo gerente de projeto faz (mesmo sem saber)
Um argumento prático do livro: se você perguntar para um gerente de projeto se ele prefere um código bom com o prazo estourado, ou um código malfeito dentro do prazo, a resposta que ele sempre vai dar é: quero algo bom, mesmo que estoure o prazo. Por quê? Porque código bom reduz custo de manutenção e de novas funcionalidades no futuro. Quanto maior a confusão dentro do código, menor a produtividade da equipe daqui a seis meses. Manter um código limpo é, na prática, a forma de aumentar a velocidade de entrega a médio prazo — não o contrário.
As seis definições de código limpo (e o que cada uma acrescenta)
Uncle Bob não define código limpo sozinho — ele pede a opinião de outros nomes conhecidos da área. Vale conhecer cada uma, porque juntas elas formam um quadro bem completo:
- Bjarne Stroustrup (criador do C++): código limpo é elegante e eficiente. Elegante no sentido de simples e fácil de ler. Eficiente no sentido de desempenho — rápido e com baixo consumo de memória.
- Grady Booch (autor de Object Oriented Analysis and Design): código limpo é simples e direto. Faz o que precisa fazer, sem enrolação, sem gambiarra.
- Dave Thomas (um dos fundadores do Extreme Programming): código limpo tem testes. É assim que você garante que o código funciona e que uma manutenção futura não quebra nada.
- Michael Feathers (autor de Working Effectively with Legacy Code): código limpo é escrito por alguém que se importa — não com o código em si, mas com as pessoas que vão dar manutenção nele depois.
- Ward Cunningham (criador do primeiro wiki): código limpo é aquele em que a linguagem parece ter sido feita sob medida para resolver aquele problema. Você lê como quem lê uma notícia de jornal.
- Ron Jeffries (outro fundador do XP): essa é, para mim, a que resume o livro inteiro em uma frase. Código limpo não tem duplicidade, tem alta expressividade e possui abstrações simples.
Vale destrinchar essa última, porque ela é praticamente um roteiro:
Sem duplicidade — se você usou uma fórmula ou lógica em um trecho do código, e precisa da mesma coisa em outro lugar, crie uma função em vez de copiar e colar. Duplicação é a receita para você esquecer de atualizar uma das cópias na próxima manutenção.
Alta expressividade — o código expressa claramente o que ele está fazendo. Bons nomes, funções bem definidas, um fluxo de leitura claro, onde uma função chama a próxima e você consegue seguir a leitura de cima para baixo.
Abstrações simples — evite padrões de projeto e arquiteturas desnecessárias. Você não precisa abstrair tudo para ter uma boa arquitetura. Abstraia só o que for realmente necessário.
Por onde começar, na prática
Se você é iniciante e quer aplicar isso amanhã, não tente adotar as dezessete regras do livro de uma vez. Comece pelo que dá mais retorno imediato: nomes e funções pequenas (os próximos dois capítulos que vou cobrir aqui no blog). São as duas mudanças mais baratas de fazer e que já entregam a maior parte do ganho de legibilidade.
// Um pequeno teste: você consegue "ler" essa função sem comentário?
bool isUsuarioAutenticado(Usuario usuario) {
return usuario.token.valido() && !usuario.token.expirado();
}
Se a resposta for sim, você já está no caminho. Se precisar de um comentário para explicar o nome da função, o problema não é a falta de documentação — é o nome.
Uma frase para guardar
Termino com a frase do Ward Cunningham, que resume bem o espírito da série toda: não é a linguagem que faz os programas parecerem simples, é o programador. A responsabilidade de manter o código limpo é sua, minha, de quem escreve — não da linguagem, não do framework, não da IDE.
No próximo artigo eu entro no capítulo 2 do livro: por que os nomes que você escolhe para variáveis, funções e classes são a base de tudo isso, e os erros mais comuns (inclusive um episódio constrangedor que aconteceu comigo com uma função chamada literalmente “tanto faz”).
📺 Assista este capítulo em vídeo: assista aqui
🎬 Série completa: acompanhe todos os capítulos na playlist Clean Code do canal FortShield
📖 Quer ler o livro?: Clean Code: A Handbook of Agile Software Craftsmanship, de Robert C. Martin — link de afiliado, ajuda o canal sem custo extra pra você.
