I came back to a project I worked on 5 years ago. It was quite “interesting” to see the code after such long pause. We had to extend the application with few new features but I wanted to make sure the code is upgraded to higher code quality level. But it’s necessary to have some facts which will prove the higher code quality.
I decided to use NDepend for it. NDepend does the static code analyze. FXCop does the similar thing BUT! NDepend creates its own DB of the metrics/data gathered from the analyzed source code. You can query the data using CQL (code query language) or you can check few charts made by NDepend. CQL is also used to build the rules which could be evaluated to ensure good degree of code quality. It’s possible to use it using while continues integration process.
But there is one essential requirement! You need to be familiar with all the code metrics and CQL. You can find the detailed info about the metrics here. It took me a while to understand (I say “to feel”) them almost all.
GRAPHS
From my point of the view the graphs are the first parts which gets the user’s focus. One of the most usefull graphs is the Abstractness vs. Instability graph (AvI graph). If you want to understand the metrics more in deep, read this.
There is another blog post here which displays the “evolution” of the understanding of the code/metrics for AvI graph. Igloocoder shows what are the most important changes to his code in order to increase the code quality. He drives you through the changes and he finished with not very successful results because the refactored assembly didn’t end-up in the “green area”.
Just to clarify the goals of the graph:
- The goal is to end-up in the green area.
- split the assembly roles:
- the abstract stable assembly – the assembly with high abstraction level and with very stable contract, used by many other assemblies
- the concrete instable assembly – the assembly with very much of the concrete implementations and which are the area of the change with smaller direct usability => that’s the reason why it’s called instable = more probable to change
Igloo’s code end-up with the refactored code located in 1 assembly and the result is:
Unfortunately he didn’t do the final step. AvI graph is about the assemblies. So I tried to finish his analyze.
If we move the interfaces into a special so-called contract assembly then we get the following solution:
NDepend will generate for us the next graph:
If we remove the code analyze of the tests and exclude ALL system assemblies from the code analyze (I call it “we clean up the noisy assemblies) then we end-up with the ideal situation:
So Igloocoder was very close to the final solution.
If you want to know how the graphs are created it’s necessary to use and understand CQL. You can query and analyze the code metrics on different levels, e.g. assemblies, namespaces, types, types.
Here is the query which I used to analyze the instability metrics for the interfaces. The result grid displays as many collumns as WHERE clauses you write into CQL query.
As you can see NDepend measures Ce (aka efferent coupling) including references to the types from system assemblies, e.g. mscorlib. From my point of the view I’d like to clean up such MUST references and don’t include them into the measurements. It’s possible to do it when you manually change the configuration NDepend created for you. Here it is:
After that the AvI graph looks like the following:
That’s all for now. We are going to include NDepend measurements into our CI process just to have a view over our code.
thoughts on coding 