Partilhar via


Métricas de código - Complexidade ciclomática

Ao trabalhar com métricas de código, um dos itens menos compreendidos parece ser a complexidade ciclomática. Essencialmente, com a complexidade ciclomática, números maiores são ruins e números menores são bons. Você pode usar a complexidade ciclomática para ter uma noção de quão difícil qualquer código pode ser para testar, manter ou solucionar problemas, bem como uma indicação de quão provável o código produzirá erros. Em um alto nível, determinamos o valor da complexidade ciclomática contando o número de decisões tomadas em seu código-fonte. Neste artigo, você começa com um exemplo simples de complexidade ciclomática para entender o conceito rapidamente e, em seguida, examina algumas informações adicionais sobre o uso real e os limites sugeridos. Finalmente, há uma seção de citações que pode ser usada para se aprofundar neste assunto.

Exemplo

A complexidade ciclomática é definida como a medição da "quantidade de lógica de decisão em uma função de código-fonte" NIST235. Simplificando, quanto mais decisões tiverem de ser tomadas em código, mais complexo é.

Vamos vê-lo em ação. Crie uma nova aplicação de consola e calcule imediatamente as métricas do seu código acessando Analisar > Calcular métricas de código para a solução.

Exemplo de complexidade ciclomática 1

Observe que a complexidade ciclomática está em 2 (o menor valor possível). Se você adicionar código de não-decisão, observe que a complexidade não muda:

Exemplo de complexidade ciclomática 2

Se você adicionar uma decisão, o valor da complexidade ciclomática sobe em um:

Exemplo de complexidade ciclomática 3

Quando você altera a instrução if para uma instrução switch com quatro decisões a serem tomadas, ela passa das duas originais para seis:

Exemplo de complexidade ciclomática 4

Vamos dar uma olhada em uma base de código (hipotética) maior.

Exemplo de complexidade ciclomática 5

Observe que a maioria dos itens, ao detalhar a classe Products_Related, tem um valor de um, mas alguns deles têm uma complexidade de cinco. Por si só, essa diferença pode não ser um grande problema, mas dado que a maioria dos outros membros tem um na mesma classe, você deve definitivamente olhar mais de perto para esses dois itens e ver o que está neles. Você pode dar uma olhada mais de perto clicando com o botão direito do mouse no item e escolhendo Ir para o código-fonte no menu de contexto. Dê uma olhada mais de perto em Product.set(Product):

Exemplo de complexidade ciclomática 6

Dadas todas as afirmações if, você pode ver por que a complexidade ciclomática está em um cinco. Neste ponto, você pode decidir que esse resultado é um nível aceitável de complexidade ou pode refatorar para reduzir a complexidade.

O Número Mágico

Como acontece com muitas métricas neste setor, não há um limite exato de complexidade ciclomática que se adapte a todas as organizações. No entanto, NIST235 indica que um limite de 10 é um bom ponto de partida:

"O número exato a ser usado como limite, no entanto, permanece um pouco controverso. O limite original de 10, tal como proposto por McCabe, tem provas de apoio significativas, mas limites tão elevados como 15 também foram utilizados com sucesso. Limites acima de 10 devem ser reservados para projetos que tenham várias vantagens operacionais em relação aos projetos típicos, por exemplo, pessoal experiente, design formal, uma linguagem de programação moderna, programação estruturada, instruções passo a passo de código e um plano de teste abrangente. Em outras palavras, uma organização pode escolher um limite de complexidade maior que 10, mas apenas se tiver certeza de que sabe o que está fazendo e está disposta a dedicar o esforço de teste adicional exigido por módulos mais complexosNIST235

Complexidade ciclomática e números de linha

Apenas olhar para o número de linhas de código por si só é, na melhor das hipóteses, um preditor muito amplo da qualidade do código. Há alguma verdade básica na ideia de que quanto mais linhas de código em uma função, maior a probabilidade de ter erros. No entanto, quando você combina complexidade ciclomática com linhas de código, então você tem uma imagem muito mais clara do potencial para erros.

Conforme descrito pelo Software Assurance Technology Center (SATC) da NASA:

"O SATC descobriu que a avaliação mais eficaz é uma combinação de tamanho e complexidade (ciclomática). Os módulos com alta complexidade e tamanho grande tendem a ter a menor confiabilidade. Módulos com baixo tamanho e alta complexidade também são um risco de confiabilidade porque tendem a ser códigos muito concisos, o que é difícil de alterar ou modificar." SATC

Análise de código

A análise de código inclui uma categoria de regras de manutenabilidade. Para obter mais informações, consulte Regras de manutenção. Ao usar a análise de código herdado, o conjunto de regras do Extended Design Guideline contém uma área de manutenção:

Conjuntos de regras de diretrizes de projeto de complexidade ciclomática

Dentro da área de manutenibilidade há uma regra para a complexidade:

Regra de manutenção da complexidade ciclomática

Esta regra emite um aviso quando a complexidade ciclomática atinge 25, para que possa ajudá-lo a evitar a complexidade excessiva. Para saber mais sobre a regra, consulte CA1502

Juntando tudo

A conclusão é que um número de alta complexidade significa maior probabilidade de erros com maior tempo de manutenção e solução de problemas. Dê uma olhada mais de perto em todas as funções que têm uma alta complexidade e decida se elas devem ser refatoradas para torná-las menos complexas.

Citações

MCCABE5

McCabe, T. e A. Watson (1994), Software Complexity (CrossTalk: The Journal of Defense Software Engineering).

NIST235

Watson, A. H., & McCabe, T. J. (1996). Testes Estruturados: Uma Metodologia de Teste Utilizando a Métrica de Complexidade Ciclomática (Publicação Especial NIST 500-235). Consultado em 14 de maio de 2011 do site da McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Métricas e Confiabilidade de Software (Anais do Simpósio Internacional de Engenharia de Confiabilidade de Software do IEEE). Consultado em 14 de maio de 2011 do site da Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159