06.10.2026 · Signal Titans Editorial

A regra de Brian Kernighan para código melhor: se for esperto demais, você não consegue depurar

Brian Kernighan falando ao microfone durante o Vintage Computer Festival East em 2025.

Brian Kernighan passou décadas cercado por alguns dos sistemas de software mais influentes da história. Uma das regras às quais ele sempre voltava era quase desconfortavelmente simples: se o seu código for esperto demais, talvez você mesmo não seja esperto o bastante para consertá-lo depois.

Brian Kernighan trabalhou 30 anos no Bell Labs, no grupo de computação ligado ao desenvolvimento do Unix, e depois entrou para o corpo docente de ciência da computação de Princeton. Foi coautor de The C Programming Language com Dennis Ritchie e escreveu alguns dos livros mais influentes sobre estilo de programação, ferramentas e linguagens.

Para alguém com esse currículo, seu conselho sobre código é surpreendentemente pouco glamouroso.

“Depurar é duas vezes mais difícil do que escrever o código pela primeira vez.”

O restante da ideia vem quase sozinho: se você usa toda a sua esperteza ao escrever um programa, sobra pouca margem para entendê-lo quando algo quebra.

Parece uma piada sobre programadores. Na verdade, é uma regra sobre complexidade.

A solução esperta tem um preço escondido

Enquanto o código funciona, esperteza pode parecer eficiência. Uma expressão densa substitui dez linhas comuns. Uma abstração genérica trata seis casos de uma vez. Um truque compacto elimina um loop, uma alocação ou uma função.

Então passam três meses.

A pessoa lendo o código já não mantém o problema inteiro na memória. As premissas originais desapareceram. Surge um bug em produção num caso que ninguém previu. E quem precisa ler o código sob pressão pode nem ser quem o escreveu.

É aí que chega o custo real da esperteza.

A pergunta importante deixa de ser “Quantas linhas eu economizei?” e passa a ser “Quantas ideias preciso manter ao mesmo tempo na cabeça para entender o que este código pode fazer?”.

O trabalho inicial de Kernighan sobre estilo de programação apontava exatamente nessa direção. O objetivo não era tornar programadores menos sofisticados. Era tornar programas mais fáceis para outros humanos raciocinarem sobre eles.

Código legível não é código de iniciante

Às vezes “mantenha simples” é entendido como “evite técnicas avançadas”. Não é isso.

Um sistema sofisticado pode exigir ideias sofisticadas. A disciplina é impedir que essa sofisticação vaze para todos os lugares.

Se uma parte do sistema realmente precisa de um algoritmo difícil, isole-a. Dê a ela um nome que revele o que faz. Coloque as premissas ao lado. Teste os limites. E deixe o restante do programa o mais entediante possível.

Bom código não prova quanto o autor sabe. Ele reduz quanto o próximo leitor precisa saber ao mesmo tempo.

Por isso clareza escala melhor do que esperteza. Uma pessoa brilhante pode entender um truque. Uma equipe, um mantenedor futuro, alguém respondendo a um incidente e você mesmo às duas da manhã precisam de algo mais durável.

A maior parte do debugging começa antes do bug

Em textos posteriores sobre depuração, Kernighan e Rob Pike lembram que a maioria dos bugs é comum e que bom debugging começa olhando evidências e raciocinando de trás para frente a partir do que o programa realmente fez.

Isso fica muito mais fácil quando o código tem limites claros.

Funções pequenas reduzem a busca. Estado explícito torna transições erradas visíveis. Bons nomes preservam intenção. Testes transformam premissas em exemplos executáveis. Logging adequado pode transformar horas de adivinhação em minutos.

Nada disso parece espetacular.

É justamente por isso que funciona.

A era da IA torna essa regra mais importante, não menos

A IA já consegue gerar código que parece funcionar mais rápido do que a maioria das equipes consegue revisar. Isso muda o gargalo.

Escrever código está ficando mais barato. Entender código, não.

Uma função gerada pode compilar. Pode passar pelo happy path. Pode até parecer elegante. Mas o problema de manutenção continua humano: que premissas ela fez? O que acontece quando falha? Essa abstração é necessária? Qual comportamento é intencional e qual é apenas um acidente da implementação gerada?

Se uma ferramenta pode produzir 500 linhas em segundos, é tentador medir progresso por output. Mas software não tem valor porque muitas linhas existem. Tem valor porque o sistema continua compreensível o suficiente para mudar com segurança.

Quanto mais rápido o código é produzido, mais cara fica a ilegibilidade.

Quatro perguntas para cada pull request

Consigo explicar esta seção sem executar mentalmente cada linha? Se não, a abstração pode estar escondendo demais ou de menos.

Quando isso falhar, onde vou olhar primeiro? Se a resposta for “em todo lugar”, os limites são fracos.

A versão comum poderia ser um pouco mais longa, mas muito mais fácil de verificar? Às vezes algumas linhas extras custam menos do que camadas extras de raciocínio.

A próxima pessoa vai entender por que isso existe? Código preserva comportamento. Nomes, estrutura e comentários preservam intenção.

Sempre haverá momentos em que uma solução esperta é realmente a solução certa.

Mas esperteza deveria ser algo que o sistema gasta de propósito, não algo que o programador exibe por padrão.

O aviso de Kernighan durou porque o hardware mudou, as linguagens mudaram e agora a IA está mudando como código é produzido — mas a pessoa depurando no final da cadeia continua com um cérebro finito.

Quanto do código de que você mais se orgulha hoje ainda parecerá óbvio para alguém tentando consertá-lo daqui a um ano?