Quantas Linhas Deve Ter Um Desenvolvimento

A verdade sobre linhas de código que ninguém quer ouvir

O mercado é cheio de gente que tenta transformar uma regra prática em dogma. A resposta curta para quantas linhas deve ter um desenvolvimento é: depende completamente do contexto. Você vai encontrar números mágicos por aí — cinquenta linhas por função, mil linhas por classe, dez mil linhas por projeto. Isso não passa de generalização barata. O que importa na prática é se o código faz uma coisa e faz bem. Se ele cumpre o contrato, é legível e mantém-se assim ao longo do tempo, o tamanho é irrelevante. Funcões gigantes podem ser um problema. Clases minúsculas também podem ser. O problema é costume, não métrica.

quantas linhas deve ter um desenvolvimento — olhando os números com cuidado

Em sistemas pequenos, eu costumo manter funções entre 10 e 30 linhas. Classes entre 50 e 150. Projetos inteiros variam drasticamente. Um serviço de API simples pode ter entre duas mil e cinco mil linhas totais e resolver um problema real. Um sistema legado complexo pode ter mais de cem mil linhas, com valor duvidoso em grande parte do conteúdo. O detalhe que a maioria esquece é que a contagem de linhas mede volume, não qualidade. O mesmo código escrito em Ruby ocupa menos linhas que em Java. Isso significa que comparar dois projetos com linguagens diferentes pela quantidade de linhas gera conclusões erradas quase sempre. Quando eu entro em um projeto novo, meu primeiro teste é ler três funções aleatórias. Se cada uma tiver mais de sessenta linhas e fizer cinco coisas misturadas, o problema é estrutural. Não adianta pedir para o desenvolvedor enxugar linhas. A raiz está na organização.

Métrica que funciona na vida real

Em vez de fixar um número, prefiro usar regras práticas que reduzem a chance de desastre. Regra do propósito único. Cada função deve resolver um problema específico. Se você precisa explicar duas etapas separadas no mesmo bloco, divida. Isso tende a manter funções naturalmente abaixo de trinta linhas. Regra da leitura contínua. Ninguém gosta de rolar a tela sem parar. Se você precisa de mais de duas telas para entender uma função, algo está errado. Isso costuma significar entre cem e cento e cinquenta linhas de arquivo como limite superior confortável.

Regra do custo de mudança. Se uma modificação simples exige tocar em dez arquivos, o acoplamento está alto. Nesse ponto, o tamanho do código individual deixa de ser o problema. O problema é a arquitetura. Na minha experiência, projetos que seguem essas regras tendem a crescer sem explodir. Projetos que ignoram acabam com arquivos de mil linhas que ninguém tem coragem de mexer. Eu já vi isso acontecer repetidamente.

Armadilhas comuns que confundem medida e qualidade

Uma das confusões mais frequentes é achar que código curto é sinônimo de código bom. Isso é perigoso. Código muito enxuto pode esconder lógica complexa em constructs obscuros. Legibilidade vence brevidade. Sempre. Outra armadilha é o número de linhas por desenvolvedor como indicador de produtividade. Isso é uma das métricas mais tóxicas que eu já vi. Desenvolvedores seniores costumam escrever menos linhas porque delegam responsabilidade a bibliotecas, abstrações e ferramentas. Desenvolvedores juniores escrevem mais linhas porque precisam explicitar tudo. Se você premia quantidade, vai punir quem pensa melhor. Existe ainda a cilada da cobertura de teste. Testes ocupam linhas. Projetos com muitos testes têm mais linhas, mas isso não os torna piores. Pelo contrário. Esse é um caso em que mais linhas podem indicar saúde, desde que o esforço seja proporcional ao domínio coberto.

Um problema real que eu encontrei e como resolvi

Eu herdei um módulo de cálculo de impostos que tinha uma função com quinhentas e setenta linhas. A regra era simples na teoria, mas o código havia acumulado exceções ao longo de três anos sem refatoração. Tentar enxugar pela quantidade de linhas gerava quebra em casos de borda que ninguém documentava. A solução que funcionou foi diferente do que eu esperava. Em vez de diminuir linhas, eu dividi a função em passos claros: parser de entrada, regra base, exceções específicas, formatação de saída. Cada passo ficou entre vinte e quarenta linhas. O total aumentou para quase o dobro. Mas cada parte tinha dono, teste isolado e compreensão imediata. Quem chegou depois conseguiu adicionar uma nova regra de impostos em dois dias. Na versão anterior, o mesmo trabalho levaria uma semana. Esse é um exemplo claro de que a pergunta quantas linhas deve ter um desenvolvimento funciona mal quando aplicada cegamente. O ganho veio da estrutura, não da redução numérica.

Limites práticos por tipo de artefato

Servidores de API. Métodos entre quinze e trinta linhas. Controllers entre cem e duzentas linhas. Se o controlador passar de duzentas, geralmente você deve mover parte da lógica para serviços. Front-end. Componentes entre trinta e oitenta linhas são confortáveis. Acima de cento e cinquenta, considere subdividir. Hooks e utilitários devem ser curtos, pois são reutilizados e testados isoladamente. Scripts de banco. Procedures com mais de cem linhas geralmente indicam que a lógica deve migrar para a aplicação. Consultas e triggers precisam ser curtas para evitar regressões silenciosas.

Bibliotecas. Cada função pública entre dez e vinte linhas é o padrão que facilita teste e manutenção. Funções privadas podem ser maiores, mas nunca tão grandes que escondam comportamento.

Quando ignorar essas números

Existem contextos válidos para arquivos longos. Arquivos de configuração gerada. Gerações automáticas de código. Bibliotecas de mapeamento onde a intenção está nos metadados, não na linha. Nesses casos, o tamanho é consequência da ferramenta, não da má decisão de design. Também há situações em que código gerado por LLMs precisa ser revisado com cuidado. O modelo pode produzir blocos longos que parecem corretos, mas contêm falhas sutis. Contagem de linhas não detecta isso. Revisão humana sim. Eu já vi modelos gerar funções de cinquenta linhas com uma condição invertida que só aparecia em produção. O tamanho era enganoso.

Como avaliar um projeto hoje mesmo

Comece com a média de linhas por função. Se estiver acima de quarenta, há espaço para melhoria. Continue com a distribuição de tamanhos de arquivo. Se houver muitos arquivos acima de duzentas linhas, investigue os motivos. Depois meça o custo de mudança: pegue uma funcionalidade simples e registre quantos arquivos e linhas você precisa tocar. Esse número é muito mais útil do que qualquer meta de linhas. Se o seu time tem pressão por entregáveis rápidos, recomendo limitar revisões de código ao essencial. Foque em clareza, divisão de responsabilidades e testes. Linhas são consequência, não objetivo. A pergunta quantas linhas deve ter um desenvolvimento continua aparecendo em entrevistas e debates. A resposta honesta é que ela não deveria existir como regra fixa. Ela existe como alarme. Se o número estiver muito alto ou muito baixo em relação ao contexto, revise a estrutura. Se estiver dentro da faixa razoável, avance com o que importa: código que funciona, que se entende e que sobrevive às mudanças.