Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao trabalhar com métricas de código, um dos itens menos compreendidos parece ser a complexidade ciclomática. Essencialmente, com complexidade ciclomática, números mais altos são ruins e números mais baixos 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 qual será a probabilidade de 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 rapidamente o conceito e, em seguida, examinar algumas informações adicionais sobre o uso real e os limites sugeridos. Por fim, há uma seção de citações que pode ser usada para aprofundar-se neste assunto.
Exemplo
A complexidade ciclomática é definida como medir "a quantidade de lógica de decisão em uma função de código-fonte" NIST235. Simplificando, quanto mais decisões tiverem que ser tomadas no código, mais complexas serão.
Vamos vê-lo em ação. Crie um aplicativo de console e calcule imediatamente suas métricas de código em Analisar > Calcular métricas de código para solução.
Observe que a complexidade ciclomática está em 2 (o menor valor possível). Se você adicionar código sem decisão, observe que a complexidade não muda:
Se você adicionar uma decisão, o valor da complexidade ciclomática aumentará um:
Quando você altera a instrução if para uma instrução switch com quatro decisões a serem tomadas, ela vai dos dois originais para seis:
Vamos dar uma olhada em uma base de código (hipotética) maior.
Observe que a maioria dos itens, conforme você faz drill down na 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 grande coisa, mas dado que a maioria dos outros membros tem um na mesma classe, você definitivamente deve 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):
Considerando todas as instruções if, você pode ver porque 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 atenda a todas as organizações. No entanto, NIST235 indica que um limite de 10 é um bom ponto de partida:
"O número preciso a ser usado como um limite, no entanto, permanece um pouco controverso. O limite original de 10, conforme proposto por McCabe, tem evidências de apoio significativas, mas limites de até 15 foram usados com êxito também. Os limites acima de 10 devem ser reservados para projetos que têm várias vantagens operacionais em relação a projetos típicos, por exemplo, equipe experiente, design formal, uma linguagem de programação moderna, programação estruturada, 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 somente 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 complexos." NIST235
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 de qualidade de 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 haver erros. No entanto, ao combinar a complexidade ciclomática com linhas de código, você tem uma imagem muito mais clara do potencial de erros.
Conforme descrito pelo Centro de Tecnologia do Software Assurance (SATC) na 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 para a confiabilidade, já que tendem a ser um código muito conciso, o que é difícil de alterar ou modificar. SATC
Code Analysis
A análise de código inclui uma categoria de regras de manutenção. Para obter mais informações, consulte Regras de Manutenibilidade. Ao usar a análise de código herdada, o conjunto de regras da Diretriz de Design Estendido contém uma área de manutenção:
Dentro da área de manutenibilidade há uma regra para complexidade:
Essa regra emite um aviso quando a complexidade ciclomática atinge 25, portanto, pode ajudá-lo a evitar complexidade excessiva. Para saber mais sobre a regra, consulte CA1502
Juntando as peças
A conclusão é que um número de alta complexidade significa maior probabilidade de erros com maior tempo para manter e solucionar problemas. Examine melhor 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), Complexidade de Software (CrossTalk: The Journal of Defense Software Engineering).
NIST235
Watson, A. H., &McCabe, T. J. (1996). Teste estruturado: uma metodologia de teste usando a métrica de complexidade ciclomática (publicação especial NIST 500-235). Recuperado 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 de software e confiabilidade (Proceedings of IEEE International Symposium on Software Reliability Engineering). Recuperado em 14 de maio de 2011, do site da Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159