Analysis of code complexity 

Complexity is everywhere. This is also true in software development. Complex code has often more bugs the simple code and it is more difficult to maintain.
Hence, it is very important to understand and measure the code complexity.

Even if personal measures like gut feeling, subjective measurement based on code review and pair-programming or code smells can be effective, objective measures can help to find where the bugs are hidding.

Lines of code (LOC) could be used but it is often discarded as accurated complexity measure. The reason is that it depends from whom is reading the code. There are many factors, such as code format, to take into consideration when using LOC as complexity measure.

The next code will show that the same code could be evaluated like 2, 4 or 8 lines of codes.

  • 2 LOC:
if (code == true) dothis;
else dothat;

– 4 LOC:

if (code == true)
    dothis;
else
    dothat;

– 8 LOC:

if (code == true)
{
   dothis;
}
else
{
  dothat;
}

Another measurement is called ciclomatic complexity developed by Thomas McCabe, which identifies the number of linearly independent paths in a function.
It is means that when a particular method does not contain any conditional operators, it will have only one independent path through the program. Any conditional statements will increase the number of paths through the method.

The first step is to create control flow graph based on a source code and then calculating the complexity based on the graph.

The formula for calculating the complexity is equals to:

edges – nodes + 2,

where each statement (conditional or not) is a node and an edge is the line connecting two nodes.
Next image will show an example:

Cyclomatic Complexity - Software testing

Example of cyclomatic complexity measurement

Many tools are available for large methods with a lots of decision points, such as CCCC and Code Analyzer. A detailed list of tools for calculating the complexity of large source code can be found in the end of this post.

The main use of this measure is to check the testability of a particul function.
McCabe gives guidelines about cyclomatic complexity. A cyclomatic complexity between 1 to 10 can be considered a simple function with little risk. Between 11 to 20 the complexity starts to be moderate as well as the risk.
When the cyclomatic complexity of a function is up 21 (or more), the risk of that function is high and that can be considered untestable is some cases (cyclomatic complexity up to 50).

It is important to measure code complexity in a software project but high complexity does not mean that a software is buggy, but that there is an higher risk to find them. Correlation between complexity metrics and bugs has been shown in numerous studies. Moreover, it is common that maintenance of complex code is extremely difficult because it is needed more time to get familiar with it, bug fixes and it is often challenging to implement new features without increase the complexity of the code.

Tools: