Intervalos de complexidade ciclomática [fechados]

Quais são as categorias de complexidade ciclomática? Por exemplo:

1-5: fácil manutenção
6-10: difícil
11-15: muito difícil
20+: aproximando-se impossível

Já faz anos que assumo que 10 é o limite. E qualquer coisa além disso é ruim. Estou analisando uma solução e estou tentando determinar a qualidade do código. Certamente a complexidade ciclomática não é a única medida, mas pode ajudar. Existem métodos com uma complexidade ciclomática de mais de 200. Eu sei que isso é terrível, mas estou curioso para saber sobre os intervalos mais baixos, como no meu exemplo acima.

Eu encontrei isso :

Os valores de referência mencionados acima de Carnegie Mellon definem quatro faixas aproximadas para valores de complexidade ciclomática:

• métodos entre 1 e 10 são considerados simples e fáceis de entender
• valores entre 10 e 20 indicam código mais complexo, que ainda pode ser compreensível; no entanto, o teste se torna mais difícil devido ao maior número de ramificações possíveis que o código pode levar
• valores de 20 e acima são típicos de código com um número muito grande de caminhos de execução em potencial e só podem ser totalmente compreendidos e testados com grande dificuldade e esforço
• métodos que vão ainda mais alto, por exemplo,> 50, certamente são insustentáveis

Ao executar métricas de código para uma solução, os resultados são verdes para qualquer coisa abaixo de 25. Não concordo com isso, mas esperava obter outras informações.

Existe uma lista de intervalos geralmente aceita para complexidade ciclomática?

Suponho que depende das capacidades da sua equipe de programação e, em grande parte, da sua sensibilidade como gerente.

Alguns programadores são fortes defensores do TDD e não escrevem nenhum código sem antes escrever um teste de unidade. Outros programadores são perfeitamente capazes de criar programas perfeitamente bons e sem erros, sem escrever um único teste de unidade. O nível de complexidade ciclomática que cada grupo pode tolerar quase certamente variará substancialmente.

É uma métrica subjetiva; avalie a configuração em sua solução Code Metrics e ajuste-a para um ponto ideal com o qual você se sinta confortável e que lhe dê resultados sensatos.

Não há categorias predefinidas e nenhuma categorização seria possível por vários motivos:

1. Algumas técnicas de refatoração apenas movem a complexidade de um ponto para outro (não do seu código para a estrutura ou uma biblioteca externa bem testada, mas de um local para outro da base de código). Ajuda a reduzir a complexidade ciclomática e a convencer seu chefe (ou qualquer pessoa que adora apresentações com gráficos cada vez maiores) de que você gasta seu tempo criando algo excelente, mas o código permanece tão ruim quanto antes.

2. Pelo contrário, às vezes, quando você refatora um projeto aplicando alguns padrões de design e programação, a complexidade ciclomática pode piorar, enquanto o código refatorado deve ficar claro: os desenvolvedores conhecem os padrões de programação (pelo menos, eles devem conhecê-los), portanto, simplifica o código para eles, mas a complexidade ciclomática não leva isso em consideração.

3. Algumas outras técnicas que não são de refatoração não afetam a complexidade ciclomática, enquanto diminuem severamente a complexidade de um código para desenvolvedores. Exemplos: adicionando comentários ou documentação relevantes. "Modernizando" o código usando açúcar sintático.

4. Existem simplesmente casos em que a complexidade ciclomática é irrelevante. Gosto do exemplo dado por whatsisname em seu comentário : algumas switchdeclarações grandes podem ser extremamente claras e reescrevê-las de uma maneira mais OOPy não seria muito útil (e complicaria a compreensão do código pelos iniciantes). Ao mesmo tempo, essas declarações são um desastre, em termos de complexidade ciclomática.

5. Como Robert Harvey já disse acima , depende da própria equipe.

Na prática, eu vi código fonte que tinha boa complexidade ciclomática, mas que era terrível. Ao mesmo tempo, vi código com alta complexidade ciclomática, mas não sentia muita dor ao entendê-lo.

Só que não existe e não poderia haver nenhuma ferramenta que indicasse perfeitamente o quão bom ou ruim é um determinado pedaço de código ou como é fácil mantê-lo . Como você não pode programar um aplicativo que diga que uma determinada pintura é uma obra-prima e que outra deve ser jogada fora, porque não tem valor artístico.

Existem métricas que são quebradas por design (como LOC ou o número de comentários por arquivo) e existem métricas que podem fornecer algumas dicas brutas (como o número de bugs ou a complexidade ciclomática). Em todos os casos, essas são apenas dicas e devem ser usadas com cautela.