26

What are the categories of cyclomatic complexity? For example:

1-5: easy to maintain
6-10: difficult
11-15: very difficult
20+: approaching impossible

For years now, I've gone with the assumption that 10 was the limit. And anything beyond that is bad. I'm analyzing a solution, and I'm trying to make a determination of the quality of the code. Certainly cyclomatic complexity isn't the only measurement, but it can help. There are methods with a cyclomatic complexity of 200+. I know that's terrible, but I'm curious to know about the lower ranges, like in my example above.

I found this:

The aforementioned reference values from Carnegie Mellon define four rough ranges for cyclomatic complexity values:

  • methods between 1 and 10 are considered simple and easy to understand
  • values between 10 and 20 indicate more complex code, which may still be comprehensible; however testing becomes more difficult due to the greater number of possible branches the code can take
  • values of 20 and above are typical of code with a very large number of potential execution paths and can only be fully grasped and tested with great difficulty and effort
  • methods going even higher, e.g. > 50, are certainly unmaintainable

When running code metrics for a solution, the results show green for anything below 25. I disagree with this, but I was hoping to get other input.

Is there a generally accepted range list for cyclomatic complexity?

closed as primarily opinion-based by user40980, Kilian Foth, amon, World Engineer Feb 6 '14 at 13:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    You found data from the Software Engineering Institute, an organization that is recognized as a leader in software engineering. I don't understand what your question is - you found a range list for cyclomatic complexity. What else are you looking for? – Thomas Owens Apr 5 '13 at 19:14
  • 1
    I've seen various ranges; that was just one example. And MS shows "green" for anything under 25. I was wondering if there was one accepted range list. Perhaps I've found it then. – Bob Horn Apr 5 '13 at 19:16
  • 1
    I agree with @ThomasOwens, but I am glad you asked this question. I upvoted it as both a question and an answer. – Evorlor Mar 13 '15 at 18:49
  • 1
    In the 2nd edition of Steve McConnell's Code Complete he recommends that a cyclomatic complexity from 0 to 5 is typically fine, but you should be aware if the complexity starts to get in the 6 to 10 range. He further explains that anything over a complexity of 10 you should strongly consider refactoring your code. – GibboK Dec 4 '15 at 8:20
19

I suppose it depends on the capabilities of your programming staff, and in no small part on your sensibilities as a manager.

Some programmers are staunch advocates of TDD, and will not write any code without writing a unit test first. Other programmers are perfectly capable of creating perfectly good, bug free programs without writing a single unit test. The level of cyclomatic complexity that each group can tolerate is almost certainly going to vary substantially.

It's a subjective metric; evaluate the setting on your Code Metrics solution, and adjust it to a sweet spot that you feel comfortable with that gives you sensible results.

  • 3
    Agreed, furthermore it depends on what is the cause of the complexity. A big switch statement that calls other functions, as part of a state machine or something similar, can have a very high complexity, despite possibly being virtually trivial to understand. – whatsisname Apr 5 '13 at 19:44
  • 1
    Aren't big switch statements typically an indication of a lack of OOP principles, such as polymorphism? State machines can be implemented in elegant ways, with OOP or design patterns. No? – Bob Horn Apr 5 '13 at 20:19
  • 3
    For some problems that 'elegance' is useful, for others it just makes things more confusing. There is no silver bullet. – whatsisname Apr 5 '13 at 23:03
  • 1
    -1 For "Other programmers are perfectly capable of creating perfectly good, bug free programs without writing a single unit test." You cannot know its bug free if you have not tested it. – Sebastien Dec 20 '16 at 19:38
  • 1
    @Sebastien: The absence of unit tests doesn't mean that it's not tested. And yes, if you're good enough, it's absolutely possible to write bug free code with no tests or a rudimentary smoke test. Admittedly, those people are a rare breed. – Robert Harvey Dec 20 '16 at 19:39
10

There are no predefined categories and no categorization would be possible for several reasons:

  1. Some refactoring techniques just move the complexity from one point to another (not from your code to the framework or a well-tested external library, but from one location to another of the codebase). It helps reducing cyclomatic complexity and helps convincing your boss (or any person who loves presentations with constantly increasing graphics) that you spent your time making something great, but the code stays as bad as it was previously.

  2. At the opposite, sometimes, when you refactor a project by applying some design and programming patterns, cyclomatic complexity can become worse, while the refactored code is expected to be clear: developers know programming patterns (at least they are expected to know them), so it simplifies the code for them, but cyclomatic complexity doesn't take this in account.

  3. Some other non-refactoring techniques don't affect the cyclomatic complexity at all, while severely decreasing the complexity of a code for developers. Examples: adding relevant comments or documentation. "Modernizing" the code by using syntactic sugar.

  4. There are simply cases where cyclomatic complexity is irrelevant. I like the example given by whatsisname in his comment: some large switch statements can be extremely clear and rewriting them in a more OOPy way would not be very useful (and would complicate the understanding of the code by beginners). At the same time, those statements are a disaster, cyclomatic complexity-wise.

  5. As Robert Harvey already said above, it depends on the team itself.

In practice, I've seen source code which had good cyclomatic complexity, but which was terrible. At the same time, I've seen code with high cyclomatic complexity, but I hadn't too much pain understanding it.

It's just that there is no and couldn't be any tool which would indicate, flawlessly, how good or bad is a given piece of code or how easy is it to maintain. As you can't program an application which will tell that a given painting is a masterpiece, and that another one should be thrown away, because it has no artistic value.

There are metrics which are broken by design (like LOC or the number of comments per file), and there are metrics which can give some raw hints (like the number of bugs or the cyclomatic complexity). In all cases, those are just hints, and should be used with caution.

  • 2
    +1 I agree with everything said. Cyclomatic complexity or LOC are just metrics that get handed to you by static code analysis. Static analysers are great tools, but they lack common sense. These metrics need to be processed by a human brain, preferably one belonging to an experienced programmer. Only then can you tell if a particular piece of software is needlessly complex. – user29079 Jan 28 '14 at 15:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.