# 11 Métricas de Código para Medir Qualidade de Desenvolvimento > As 11 métricas de código para medir qualidade de desenvolvimento incluem complexidade ciclomática, acoplamento, coesão, duplicação, profundidade de herança, cobertura de testes, tempo de compilação, taxa de defeitos, manutenibilidade, tamanho de funções e dívida técnica. Essas métricas objetivas revelam a saúde real do software, orientando decisões técnicas para melhorar a manutenibilidade e reduzir riscos. *TNT Web · Apps e Software · 21 de julho de 2026 · Eloá Pimentel* Medir qualidade de código vai além de contar linhas. Conheça 11 métricas objetivas, de complexidade ciclomática a acoplamento, que revelam a saúde real do seu software e orientam decisões técnicas. Medir qualidade de código é uma tarefa que vai além da intuição. As principais métricas de qualidade de código incluem complexidade ciclomática, linhas de código (LOC), profundidade de herança, acoplamento entre classes, coesão (LCOM), cobertura de testes, duplicação, dívida técnica, taxa de bugs, tempo de build e violações de estilo. Elas ajudam a quantificar manutenibilidade, legibilidade e confiabilidade do software. Em vez de confiar apenas em revisões manuais, equipes de desenvolvimento usam essas 11 métricas para transformar qualidade em dados objetivos. Cada uma revela um aspecto diferente, desde o risco de introduzir bugs até o esforço necessário para estender uma funcionalidade. A seguir, o ranking das mais relevantes, da mais impactante para a mais operacional. ## 1. Complexidade Ciclomática A complexidade ciclomática mede o número de caminhos independentes no código-fonte de uma função. Quanto maior o número, mais difícil é testar e entender o fluxo. Uma função com complexidade acima de 10 já exige atenção, acima de 20, refatoração é recomendada. Ferramentas como SonarQube calculam esse número automaticamente. O hábito revela que funções com alta complexidade concentram a maior parte dos defeitos em produção. ## 2. Linhas de Código (LOC) LOC conta o total de linhas do código-fonte, excluindo comentários e espaços em branco. Embora seja a métrica mais simples, ela correlaciona-se com esforço de manutenção: módulos com mais de 500 linhas tendem a ser menos legíveis. O valor não é absoluto, linguagens como Java geram mais LOC que Python para a mesma lógica. Use LOC como alerta relativo, não como meta de redução. ## 3. Profundidade de Herança (DIT) DIT mede quantas classes ancestrais uma classe possui na hierarquia de herança. Uma profundidade acima de 4 indica risco de acoplamento excessivo e dificuldade de entender o comportamento herdado. Em sistemas Java, por exemplo, heranças profundas tornam a depuração mais lenta. O ideal é manter DIT entre 1 e 3. ## 4. Acoplamento entre Classes (CBO) CBO conta quantas classes uma classe depende diretamente. Valores altos indicam que uma mudança em uma classe pode propagar efeitos colaterais para muitas outras. Módulos com CBO acima de 10 costumam estar frágeis para alterações. A métrica é especialmente útil em arquiteturas orientadas a objetos. ## 5. Falta de Coesão em Métodos (LCOM) LCOM mede o quanto os métodos de uma classe compartilham atributos. Um LCOM alto significa que a classe faz coisas demais, viola o princípio da responsabilidade única. Classes com LCOM acima de 80% são candidatas a refatoração em classes menores e mais focadas. ## 6. Cobertura de Testes Cobertura de testes indica a porcentagem de linhas, branches ou caminhos executados pelos testes automatizados. O padrão de mercado é buscar pelo menos 70% de cobertura de linhas. Porém, cobertura alta não garante qualidade: testes mal escritos podem cobrir código sem testar lógica. A métrica deve ser combinada com análise de mutação para ser confiável. ## 7. Duplicação de Código A duplicação mede blocos de código idênticos ou similares espalhados pela base. Cada bloco duplicado significa que um bug precisa ser corrigido em N lugares. Ferramentas como PMD e SonarQube apontam duplicações acima de 10 linhas consecutivas. Reduzir a duplicação diminui o custo de manutenção em até 30%, segundo estimativas da indústria. ## 8. Dívida Técnica Dívida técnica quantifica o esforço necessário para corrigir problemas estruturais no código. É expressa em dias-homem ou como uma porcentagem do custo total de desenvolvimento. Ferramentas como SonarQube calculam a dívida com base em violações de regras. Um índice acima de 5% do custo total é considerado alto e merece plano de redução. ## 9. Taxa de Bugs por Módulo Essa métrica conta a quantidade de defeitos reportados por módulo ou componente em um período. Módulos com alta taxa de bugs indicam código frágil ou mal testado. O time pode usar essa métrica para priorizar refatorações. O dado deve ser cruzado com complexidade ciclomática para confirmar a causa raiz. ## 10. Tempo de Build Tempo de build mede quanto tempo leva para compilar e empacotar o sistema completo. Builds acima de 10 minutos desestimulam integrações frequentes e aumentam o ciclo de feedback. Times ágeis buscam builds abaixo de 5 minutos. Reduzir dependências desnecessárias e modularizar o projeto são ações diretas para melhorar essa métrica. ## 11. Violações de Estilo e Padrões Essa métrica conta quantas regras de formatação, nomenclatura e boas práticas são quebradas no código. Ferramentas como ESLint, Checkstyle e Pylint geram relatórios automáticos. Embora pareça superficial, um alto número de violações indica falta de disciplina e dificulta a leitura do código por diferentes membros da equipe. ## Como escolher as métricas certas Não existe um conjunto único que sirva para todo projeto. Para sistemas legados, priorize dívida técnica e duplicação. Para projetos novos, foque em complexidade ciclomática e cobertura de testes. O importante é automatizar a coleta e discutir os resultados em retrospectivas. Ferramentas como SonarQube, CodeClimate e DeepSource integram essas métricas em dashboards contínuos. ## FAQ ### Qual a métrica mais importante para qualidade de código? A complexidade ciclomática é a mais citada porque se correlaciona diretamente com dificuldade de teste e probabilidade de defeitos. Ela é útil em qualquer linguagem e fácil de automatizar. ### Como medir dívida técnica? Ferramentas como SonarQube calculam a dívida técnica somando o tempo estimado para corrigir cada violação de regra. O resultado é expresso em dias ou porcentagem do custo total do desenvolvimento. ### Cobertura de testes acima de 90% é garantia de qualidade? Não. Cobertura alta pode esconder testes mal escritos que não avaliam resultados. A métrica deve ser combinada com análise de mutação e revisão de casos de teste. ### Qual a diferença entre acoplamento e coesão? Acoplamento mede dependência entre classes; coesão mede o quanto os métodos de uma classe estão focados em uma única responsabilidade. Idealmente, acoplamento baixo e coesão alta. ### Devo usar todas as 11 métricas ao mesmo tempo? Não. Comece com 3 a 5 métricas alinhadas aos objetivos do time. Adicione novas gradualmente. O excesso de métricas pode gerar ruído e paralisia de análise. ### Ferramentas gratuitas medem essas métricas? Sim. SonarQube Community Edition, PMD, ESLint e Pylint são gratuitos e cobrem a maioria das métricas listadas. Para dívida técnica e cobertura de testes, SonarQube é a opção mais completa. --- Fonte (canonical): https://tntweb.com.br/apps-e-software/11-metricas-de-codigo-para-medir-qualidade-de-desenvolvimento/