Relation between LOC and Cyclomatic Complexity

Question

Is there something that ratio of the metrics LOC and Sum Cyclomatic Complexity in a project with many modules can talk about?

Does it show the logical complexity of a module/project?

Answer 1

The paper posted in John R. Strohm's answer is somewhat misleading. Although I don't disagree that there is a relationship between cyclomatic complexity and lines of code, it looks like cyclomatic complexity has been misused by applying cyclomatic complexity at the project level.

First, cyclomatic complexity should be applied at a method level, not a project level. Generally, when you write unit-level tests, you are targeting a method. You can then use cyclomatic Complexity to determine the number of paths through the method, which corresponds to the number of well-written unit tests you would need to provide coverage of all of those paths. Once you expand upwards to classes and projects, cyclomatic complexity still counts every path through the program, including ones that are mutually exclusive. So you end up with numbers that are not likely or nearly impossible (maybe a cosmic ray will flip a bit at the right point causing your program to go down one of these mutually exclusive paths).

I found a different paper that does clearly support this idea: Empirical analysis of the relationship between CC and SLOC in a large corpus of Java methods by Landman, Serebrenik, and Vinju. They explicitly looked at Java methods (not entire programs) and the relationship between cyclomatic complexity and source lines of code. However, when looking at entire classes, they did find that a relationship does emerge (which is what was found in the study in the previous answer).

Second, cyclomatic complexity is slightly more reasonable than lines of code when considering the working memory of humans. If you have a well designed method with a good name and good internal names (called methods, variables) that performs a cohesive set of operations, higher cyclomatic complexity will become a barrier to understanding before source lines of code. Although longer methods, in terms of lines of code, also tend to have higher cyclomatic complexity, the number of cyclomatic complexity is likely to make it easier to reason about a method being too complex for a person to understand.

If you're trying to understand the complexity of a system, cyclomatic complexity is better than source lines of code. With properly tools, it's relatively easy to count. It also doesn't require much thought as to how to apply it to assessing the understandability or testability of methods. But it doesn't scale up to whole projects.

Answer 2

See Cyclomatic Complexity and Lines of Code: Empirical Evidence of a Stable Linear Relationship, in J. Software Engineering & Applications, 2009, 2: 137-143.

From the Abstract:

"We undertake the largest statistical study of this relationship to date. Employing modern regression techniques, we find the linearity of this relationship has been severely underestimated, so much so that CC can be said to have absolutely no explanatory power of its own."

In other words, don't waste your time on Cyclomatic Complexity. Just count SLOC and be done with it.

Yes, for the hecklers in the cheap seats, I know that SLOC can be gamed. I also know that a sane software engineering operation is going to apply very stern disciplinary measures to anyone who is found at code review to have done so.