Hi @Shubhashini_Patil,
Disclaimer: I’m sharing my personal opinion here, it is not an official point of view at Sonar.
First, cyclomatic complexity does not map very well to the actual complexity of the source code. I think our cognitive complexity metric is a much better fit for how developers think about source code.
Secondly, the main goal of cyclomatic complexity at the function level is to detect when a function becomes too large to be testable and, by extension, too large to understand and improve. It is actionable: After a threshold, the function should be split into smaller and more manageable units.
On the other hand, since cognitive complexity is monotonically increasing, a large project will always have a larger complexity than a small one. What is the meaning of a total complexity of 9000? Does it mean the code is badly written, badly architectured, or too complex, or does it just mean that the project has many features? I don’t think a complexity value (cyclomatic or cognitive) at the project level is very actionable.
We could be tempted to compute an average complexity for a project, but it is usually not very meaningful, like all averages. A ton of one-liners would hide problematic very complex functions. Raising an issue on all complex functions works better.
Of course, even if all individual functions have a low complexity, the project as a whole can still be too complex for what it is doing. But I think that at the project level, it is probably better to look at how the different functions (and higher-level structures, such as classes) interact with each other to get a grasp of the project’s health. Many such metrics exist (for instance, coupling between components or component cohesion). These metrics are not as easy to act on as complexity metrics (this is why they are not a strong focus of our products for now), but I think they better represent the complexity of a project.
We recently introduced rules targeting cyclic dependencies, and it goes in the direction of improving our offering for rules that work at the scale of the full project (and there is more to come in the future).
Would you agree with this point of view?