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 :

Read the rest of this page »

Discussing Cyclomatic Complexity

Googling on Cyclomatic Complexity (CC), gives some interesting results… Among those results, you’ll find the two following definitions :

  • A measure of the complexity of a software module, equal to e – n + 2, where e is the number of edges in the control flow graph and n is the number of nodes in this graph (that is, the cyclomatic number of the graph plus one)
  • A measurement of the intricacy of a program module based on the number of repetitive cycles or loops that are made in the program logic. It is used as a general measure of complexity for software quality control as well as to determine the number of testing procedures

Those two definitions, though perfectly true, are one of the reason for Sonar to exist: going away from the fact that code source quality is a notion only accessible to elite. Sonar is about democratization of the source code quality concepts to be understandable and usable by every stakeholder in a development project.

Read the rest of this page »

© 2008-2016, SonarSource S.A, Switzerland. All content is copyright protected. SONARQUBE, SONARLINT and SONARSOURCE are
trademarks of SonarSource SA. All other trademarks and copyrights are the property of their respective owners. All rights are expressly reserved.