Static code analysis

The big idea with static code analysis is that we can analyse source code of our application to detect some kind of errors or issues (e.g. potential null reference). We can also analyse our source in terms of code quality metrics (e.g. method with too many parameters).

It should, in general, let us have an overview of what’s happening in our code base (especially important with big code bases) and we can also use it to enforce certain code standards. Nowadays you will most likely integrate it with your CI pipeline to detect issues as soon as possible.

Lets take a look at few examples of things that we can do with it.

Cyclomatic complexity

Have you heard about it? It’s a metric that helps measure complexity of software. I won’t go into details here, but it basically measures how many control flow statements are in the code (e.g. if). Let me give you an example. If there is a simple method, with no control flow instructions then we have cyclomatic complexity equal to 1 (the simplest possible method), but if you have a method that contains single if statement then there are two paths the code can take during exection. Such condition, will increase cyclomatic complexity to 2.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Cyclomatic complexity = 2
public bool IsAdult(int birthYear)
{
    var yearsOfLife = DateTime.Today.Year - birthYear;
    if (yearsOfLife >= 18)
    {
        return true;
    }
	
    return false;
}

So, if we want to make our code less complex or at least something that will let us detect parts of the code that is too complex, then we can use this metric.

Detecting unused code

This point doesn’t need much explanation. I will only point out that this will be particularly useful in large code bases. In general, I’m not a fan of keeping of old code “just in case” (after all we do have everything in our source control and we can make branches, tags and so on) and the main reason is that someone, unknowingly, might use that old/obsolete/unmaintained code without know that there is a new or better way to handle the task at hand.

Dependency graph

It’s possible to generate a graph that will show us dependencies and interdependences between parts of code (projects, modules, libraries). While it doesn’t seem like it’s a big deal, it will let you quickly spot wrong dependencies and have a general overview of your projects.

Drawbacks

Drawbacks, as usual, must exist. Static analysis will not be able to detect all kind of issues and it can report false positives because it won’t “understand” everything. It should be considered first (automated) layer of code review that will help use catch some errors and quality issues.

Practical example using nDepend to analyse nopCommerce code base

Note: I’ve used time limited trial version of nDepend (2025.1.3) and I haven’t received any compensation for reviewing it.

Note 2: I’ve used current nopCommerce source code from develop branch (I think, that it’s build on top of v. 4.80).

nDepend seems to be primarliy focused on code quality. You can run in three different ways:

1. console for integrating with build and CI in general
2. power tools which is a set of open source static analuzers
3. plugin that will integrate it into Visual Studio
4. stand alone which is a separate application

I’ve used only the stand alone mode. Application interface reminds me of Visual Studio interface. I guess that they wanted it to look familiar to .NET developers.

Without any further ado, lets take a look a the report for nopCommerce:

As we can see it found some issues in the code. I’m not going to review them all here, but let’s take a look at one of the issues in critical category:

As you can see the description is rather detailed, which might come in handy, but I got intrigued by that Debt / Annual interest / Breaking Point links up there.

It turns out that these are measure of technical debt. Each kind of rule violation comes with these estimations. Instead of explaining it here I’ll redirect you to nDepend technical debt documentation that explains it.

One more thing that I want to show you is dependecy graph. It’s quite large on it’s own, but it will give you some idea:

Conclusion

Static code analysis can give you some useful insights about your code base. However, you will actually need to spent some time on your code to incorporate those insights. In my opinion you will need to integrate it into your development pipeline (CI, IDE) or you will simply skip it.

I cannot really give any strong opinion of nDepend. I have only used it for a short time on single project. Personally I would need it to use for a few weeks in commercial settings, so that I could use it everyday on software that I created. However, if you care about code quality it’s certainly worth a try (at the moment they do have a 14 day trial version available). There is also a number of features that I did not review. One such features is a Code Rule and Code Query over LINQ, which basically lets you run linq query to analyse your code base, so you could for example get a list of methods that have more than 100 lines of code.

One thing that I wanted to point out is nDepend documentation which contains some interesting insights. You can, for example, review Metrics on Methods rules used by analyzer.