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?

2 Answers 2


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.


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.

  • Thank you so much for the answer. So you mean, CC is almost linear with LOC and SLOC can particularly replace CC at any point, and it can be a standalone metric? Jul 31, 2017 at 8:17
  • Because the PDF says 'CC has no explanatory power of its own' and hence if I use SLOC instead of CC, will it be self explanatory? Jul 31, 2017 at 8:21
  • @ChristyWald It basically means that you can replace a CC only model with a SLOC only model and not see much difference, or equivalently adding one to the other doesn't improve the predictive power of the model
    – Caleth
    Jul 31, 2017 at 8:56
  • 3
    As I posted in my answer, the paper you linked to misuses cyclomatic complexity by applying it across an entire project instead of within a method. Applying CC at the wrong scale (projects or classes instead of methods) leads to other problems, such as not being able to relate its output to test cases. Properly using CC makes it a much better metric than SLOC for understanding complexity.
    – Thomas Owens
    Jul 31, 2017 at 9:24
  • Wait, what do you mean by not wasting your time a CC ? Do you mean at the project scale, or even method ?
    – Walfrat
    Jul 31, 2017 at 9:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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