Você entra numa reunião de code review e alguém solta: “isso aqui fere o Clean Code”. Você concorda, balança a cabeça, mas por dentro não faz ideia do que a pessoa quis dizer com aquilo. Não é um framework, não é uma ferramenta que você instala, não é um linter. Clean Code é, antes de mais nada, um livro — e um conjunto de ideias que esse livro organizou e popularizou. Vou explicar o que é, de onde vem, e por que resolvi dedicar uma série inteira de vídeos e agora de artigos a ele.
O livro e o autor
Clean Code é um livro de Robert C. Martin, mais conhecido como Uncle Bob. Ele é profissional de software desde 1970 — mais de 50 anos de estrada — e atua como consultor internacional desde 1990. Conhece de perto linguagens como C++, Java e C#. Ele também mantém um programa curto, de 3 a 6 minutos, chamado “Morning Bath Robe Rant” (o desabafo matinal de roupão), onde comenta sobre boas práticas de código. Se você usa Twitter/X, vale segui-lo como @unclebobmartin.
O livro não é recente — foi escrito lá por 2010 — mas a maior parte do conteúdo dele não envelheceu. Isso porque ele não fala de uma linguagem específica ou de uma ferramenta específica. Ele fala de como você organiza o pensamento dentro do código, e isso não muda de framework para framework.
Por que eu decidi estudar isso agora
No começo de 2025 eu tinha acabado de estudar Design Patterns e decidi voltar a estudar a base da criação de código — relembrar coisas que eu já tinha visto no passado e que, pela falta de uso constante, eu precisava reforçar. Peguei o Clean Code para estudar capítulo a capítulo, com anotações no caderno, e resolvi gravar isso em vídeo. Não é aula de faculdade, é o registro de alguém estudando e compartilhando o que está aprendendo — inclusive porque ensinar é, na prática, a forma mais eficiente de fixar o que você aprendeu.
Um ponto importante: os exemplos originais do livro são em Java. Eu apresento a maioria dos meus exemplos em C++, porque é a linguagem que uso no meu trabalho com sistemas embarcados. Isso não muda o conteúdo. Os conceitos que o Uncle Bob descreve são agnósticos de linguagem — dá para aplicar em Java, Python, PHP, JavaScript, C++, tanto faz. O que muda é só a sintaxe.
O que essa série (e este blog) não é
Vale deixar claro: nem os vídeos nem estes artigos substituem a leitura do livro. O conteúdo aqui é o resumo das minhas percepções sobre cada capítulo — o livro sempre vai trazer mais nuance e mais exemplos do que cabe num vídeo de vinte minutos ou num post de mil palavras. Se o assunto te interessar de verdade, a recomendação é ler o livro na íntegra.
Também não é um curso de programação. A ideia aqui pressupõe que você já sabe o básico — o que é um for, um if, uma função. Não vou explicar sintaxe de linguagem nenhuma. O foco é inteiramente em como organizar e escrever o código que você já sabe produzir.
Uma prévia rápida do que “código limpo” significa
Sem entrar em detalhe agora — isso é assunto do próximo artigo, onde reviso as definições que o próprio Uncle Bob coletou de outros nomes importantes da área —, dá para adiantar a essência com um exemplo simples.
// Antes
int d(int l, int w) {
return l * w;
}
// Depois
int calculaAreaRetangulo(int largura, int comprimento) {
return largura * comprimento;
}
As duas funções fazem exatamente a mesma coisa. Mas a primeira não te diz nada — você precisa ler o corpo da função para adivinhar o que ela calcula. A segunda se explica sozinha. Essa diferença, multiplicada por milhares de linhas em um sistema real, é o que separa um projeto que qualquer pessoa consegue dar manutenção de um projeto que só quem escreveu entende (e, seis meses depois, nem quem escreveu entende mais).
Clean Code, resumindo bem grosseiramente antes de entrarmos fundo nos capítulos: é o conjunto de práticas que fazem seu código continuar legível, testável e alterável conforme o projeto cresce — em vez de virar um território que ninguém quer pisar.
Por que isso importa pra sua carreira, não só pro seu código
Um ponto que aparece bastante no livro e que eu reforço bastante: gerentes de projeto preferem esperar um pouco mais e receber um código bom do que receber algo malfeito dentro do prazo. Isso parece contraintuitivo à primeira vista, mas faz sentido quando você entende o motivo — código ruim custa caro depois, em forma de manutenção lenta, bugs recorrentes e medo de mexer em qualquer coisa. Código limpo reduz esse custo futuro. É investimento, não perfeccionismo.
Como vou estruturar o conteúdo
Vou seguir a estrutura do próprio livro, capítulo a capítulo: nomes, funções, comentários, formatação, tratamento de erros, testes unitários, classes e os princípios SOLID, e por fim uma discussão sobre os limites do Clean Code — inclusive quando ele pode custar performance, que é um ponto que o próprio Uncle Bob não trata no livro.
Se você tem o livro em casa e sentir que faltou algo em algum artigo, ou se tiver dúvida, comenta — vou ler e responder. E se você ainda não tem o livro, vale a leitura completa antes ou em paralelo aos próximos textos daqui. No próximo artigo eu entro direto nas definições de código limpo segundo o próprio Uncle Bob e mais cinco nomes conhecidos da área — inclusive a analogia que eu prefiro usar no lugar da do livro para descrever o que é um código ruim.
📺 Assista este capítulo em vídeo: clique aqui para ver no YouTube
🎬 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ê.
