Managing cyclomatic complexity to increase maintainability
In a previous post on Cyclomatic Complexity (CC), I discussed two ideas:
- Total CC only means lots of logic has been implemented, it is not a qualitative measure
- On the contrary, average CC per method and per class are example of qualitative measures that can be derived from CC metric. For instance, high average CC by class could mean bad level of cohesion. Lack of cohesion means that a class is performing several unrelated tasks.
and I concluded that in terms of quality, what matters is not the total cyclomatic complexity of a program but a moderated and well distributed level of CC for each components (packages, classes, methods), i.e. breaking the problem down into manageable components. When those components are not small enough, maintainability decreases.
Today, I am going to explain how to use Sonar in order to identify risky programs or components in terms of maintainability before they can be fixed. In other words, how to detect if an application is more of :
- a monolithic type of animal (and therefore little evolutive and subject to side effects in case of modifications)
- a pretty modular project, following a good Object Oriented design (at least in term of cohesion)
There are 3 complementary approaches to do so :