Additional Option for Cyclomatic Complexity

[jasonmk]

I'd like to see an option for Cyclomatic Complexity that allows me to ignore 'when' statements when computing the complexity of a method. Basically, any method with a case statement is virtually guaranteed to exceed the Complexity limit. If I only had 1 or two possible conditions, I'd probably be using if/elsif/else anyways. Case statements are great for a method that branches off into a number of different paths, but that doesn't make it inherently complex.

[jonas054]

@jasonmk I think that, broadly speaking, cyclomatic complexity is a metric that tells you how difficult is this to test. What you're looking for is slightly different, how difficult is this to read. So if we're going to add this configuration option, it's probably best to create a new cop for it, because without the whens, the metric isn't really cyclomatic complexity.

@bbatsov @yujinakayama What do you think about adding a Metrics namespace? Cops such as ClassLength, MethodLength, and CyclomaticComplexity could be moved there.

[bbatsov]

👍 for Metrics namespace.

[jasonmk]

Awesome, that sounds great.

[yujinakayama]

👍 for Metrics namespace too.

[dpashk-figma]

Just want to add my two cents. While it's true that the classic cyclomatic complexity is a strict metric of testability, practical applications have led to the creation of its variant, modified complexity.

Modified cyclomatic complexity is almost exactly the same as the classic cyclomatic complexity, except that a switch statement only increases the value by 1 regardless of how many case statements it contains.

A number of other code analysis tools implement this metric. See:

• https://github.com/terryyin/lizard?tab=readme-ov-file#options (-m, --modified option)
• Understand
• Matlab's checkcode
• CodeSonar

Given that it's common enough in the industry, I propose that you still consider adding an option to the existing cyclomatic complexity rule, or accepting a PR for a separate Modified Complexity rule (it'll probably just inherit from the existing Cyclomatic Complexity rule). Note that this is still different from the PerceivedComplexity rule that now exists.

I'd be happy to make a contribution either way. What do you think?