X-ray StoneAssemblies.MassAuth with NDepend

Introduction

A long time ago, I wrote this post Why should you start using NDepend? which I consider as the best post I have ever written or almost ;)

NDepend is a static analysis tool for .NET, and helps us to analyze code without executing it, and is generally used to ensure conformance with the coding guidelines. As its authors use to say, it will likely find hundreds or even thousands of issues affecting your codebase.

After the first pre-releases of StoneAssemblies.MassAuth I decided to X-ray it with NDepend. I attach a new NDepend project to StoneAssemblies.MassAuth solution, filter out the test and demo assemblies, and hit the analyze button.

Attach new NDepend Project to Visual Studio Solution 

Now, I invite you to interpret some results with me. So, let's start.

Interpreting the NDepend analysis report

One of the outputs of the analysis is a web report. The main page includes a report summary with Diagrams, Application Metrics, Quality Gates summary, and Rules summary sections.

NDepend Report Summary

Navigation Menu

It also includes a navigation menu to drill through  more detailed information including Quality Gates, Rules, Trend Charts, Metrics, Dependencies, Hot Sports, Object-Oriented Design, API Breaking Changes, Code Coverage, Dead Code, Code Diff Summary, Build Order, Abstractness vs. Instability and Analysis Log.

But let's take a look at these summary sections.

Diagrams

The diagrams section includes Dependency Graph, Dependency Matrix, Treemap Metric View and Abstractness vs. Instability. 

Dependency Graph

Dependency Matrix

Treemap Metric View (Color Metric Coverage)

So far I understand these metrics, actually, I can interpret them relatively easily. 

But, wait for a second. What is this Abstractness versus Instability? 

Abstractness versus Instability

According to the documentation the Abstractness versus Instability diagram helps to detect which assemblies are potentially painful to maintain (i.e concrete and stable) and which assemblies are potentially useless (i.e abstract and instable).

Abstractness: If an assembly contains many abstract types (i.e interfaces and abstract classes) and few concrete types, it is considered as abstract.

Instability: An assembly is considered stable if its types are used by a lot of types from other assemblies. In this context stable means painful to modify.

Component	Abstractness (A)	Instability (I)	Distance (D)
StoneAssemblies.MassAuth	0	0.96	0.03
StoneAssemblies.MassAuth.Rules	1	0.4	0.28
StoneAssemblies.MassAuth.Messages	0.43	0.62	0.04
StoneAssemblies.MassAuth.Hosting	0.14	0.99	0.09
StoneAssemblies.MassAuth.Rules.SqlClient	0.17	1	0.12
StoneAssemblies.MassAuth.Server	0	1	0
StoneAssemblies.MassAuth.Proxy	0	1	0

None of StoneAssemblies.MassAuth's components seem potentially painful to maintain or potentially useless. But, I have to keep my eyes on StoneAssemblies.MassAuth.Rules, because of the distance (D) from the main sequence. Actually, another candidate to review is StoneAssemblies.MassAuth.Messages since ideal assemblies are either completely abstract and stable (I=0, A=1) or completely concrete and instable (I=1, A=0).

Application Metrics 

The application metrics section shows the following summary.

Application Metrics

Looks like some metrics depend on a codebase. Since this is the first I run NDepend's analysis over StoneAssemblies.MassAuth code, it hasn't noticed any difference with previous executions. But this help me to be alert about the low 66.99% value for the tests coverage, the 3 failures for quality gates, the violations of 2 critical rules and 15 high issues.

Quality Gates

In this section is possible to view more details on the failing quality gates. The percentage of coverage, the critical rules violated and the debt rating per namespace.

Quality Gates

Wait for a second again. What is debt rating per namespace means? 

According to the documentation the rule is about to forbid namespaces with a poor debt rating. By default, a value greater than 20% is considered a poor debt rating.

Namespaces	Debt Ratio	Issues
StoneAssemblies.MassAuth.Services	39.01	8
StoneAssemblies.MassAuth.Services.Attributes	37.62	3
StoneAssemblies.MassAuth.Server	23.67	6
StoneAssemblies.MassAuth.Rules.SqlClient .Rules	36.24	3

Rules summary

The final section is the Rules summary. It listed the issues per rules in the following table. 

Rules summary

NDepend indicates to me that I violated 2 critical rules. One to avoid namespaces mutually dependent and the other to avoid having different types with the same name. That sounds weird, but who knows, even I can make mistakes ;)

What's next?

I the near future, I will be integrating the NDepend analysis as part of the build process, therefore I could easily share with you the evolution of this library in terms of quality. If you are interested in such an experience wait for the next post.

As you already know, StoneAssemblies.MassAuth is a work in progress, which includes some unresolved technical debts. But, as I told you once, it is possible to make mistakes (critical or not), but be aware of your code quality constantly makes the difference between the apparent and intrinsic quality of your sources. If you are a dotnet developer, NDepend is a great tool to be aware of your code quality. 

Yeah, you are right, I have some work to do here in order to fix this as soon as possible but also remember, StoneAssemblies.MassAuth is also an open-source project, so you are welcome to contribute ;)

Can NDepend 6 and SONAR work together?

Introduction

As I wrote in this post, one of the greatest feature of NDepend were its “great Visual Studio integration in order to display your technical debt directly inside the IDE”.

NDepend can also be integrated as part of your continuous integration pipeline in order to make the analysis of technical debt results public for the whole team (or just break the build under certain conditions). There are a lot of official documentation about how integrate NDepend 6 with Team City (as a build server) or SONAR (as a quality metric tool).

But let’s start with my own experience setting up NDepend 6 and SONAR and checks the benefits of integrates both tools.

Integrating NDepend with SONAR

NDepend 6 comes with support for SONAR integration. The process is pretty forward and is well described on the documentation. After follow such steps you will get all NDepend’s rules imported into SONAR and you can activate them into a Quality Profile for instance the Full Analysis for C#. 

NDepend rules imported in SONAR

The issues could start when you run an analysis for large projects with several violations. If you run (the runner) with –X the stack trace will show you the java.lang.OutOfMemoryError as the exception. But nothing that can’t be solved following this recommendations: 

1. Run sonar-runner with x64 JRE. 
2. Increase the heap size by turn this line:

%JAVA_EXEC% %SONAR_RUNNER_OPTS% -cp "%SONAR_RUNNER_HOME%\lib\sonar-runner-dist-2.4.jar" "-Drunner.home=%SONAR_RUNNER_HOME%" "-Dproject.home=%PROJECT_HOME%" org.sonar.runner.Main %*

             into this one

%JAVA_EXEC% -Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% -cp "%SONAR_RUNNER_HOME%\lib\sonar-runner-dist-2.4.jar" "-Drunner.home=%SONAR_RUNNER_HOME%" "-Dproject.home=%PROJECT_HOME%" org.sonar.runner.Main %*

            in the sonnar-runner.bat file.

The results

SONAR is an isolated server that receive the results from “inspection agents”. Actually the inspection results are committed directly into SONAR database and the SONAR web application or dashboard displays the results in a centralized way. 

So, as you expected (and so do I), after run an inspection via sonar-runner, the NDepend's rules violations are displayed as SONAR's issues, just like this.

NDepend's violations as SONAR's issues

So, now you can manage (assign, resolve, or comment) such issues trougth SONAR interface. 

Conclusions

As you should know at this point, the answers is yes. NDepend 6 can work together with SONAR. But as you can also see I have a lot of work to do. So, I’m not sure what I’m doing writing this blog post ;).

SONAR dashboard

PS: This is not a "Do as I say, not as I do" post. As I also said, the "important thing is, not to accumulate technical debt and fix it as soon as it is detected". The sample reports shown on this post intentionally includes source with a tons of defects. Most of them comes from tests / PoC assemblies and auto-generated code.

Why should you start using NDepend?

Introduction

This weekend I finished painting my apartment. Then I laid on the floor, looking at the ceiling, started taking some shots and talking to myself:

A) Yes, it looks great and with this new lamp in the middle of the living room, everything looks perfect.	B) But what is that I see at the corner? Let me get a closer shot.	C) Oops!!! I made a mistake, I need to fix it ASAP ;)

Yes, I know, I’m not a professional painter. Therefore, I don't have the right tools to alert me about these technical debts while I’m painting. 

Such experience reminded me that I’m a software developer and recently acquired the right tool to detect such “dark spots” – a.k.a technical debt – of the source code while I’m coding. Its name is NDepend.

What is NDepend?

SONAR Web Report

NDepend is a static analysis tool for .NET managed code. As you should know static analysis is about analyzing code without executing it and is generally used to ensure conformance with the coding guidelines.

NDepend is not the only tool available for static analysis code for .NET, there are several tools including Code Violation Detection Tools like Fxcop, Clocksharp, Mono.Gendarme or CodeIt.Right,  Quality Metric Tools like Nitriq, SONAR or NDepend itself, or just Checking Style Tools like StyleCop, Agent Smith.

Actually, I currently use SONAR with its seamless integration with the build process in order to continuously manage code quality in centralized reports of technical debts.

NDepend also has integration with the build process, but from my point of view, one of its key features is the great Visual Studio integration in order to display your technical debt directly inside the IDE.

NDepend Dashboard in Visual Studio

Let's take a look at a very quick start with NDepend.

A very quick start with NDepend

Quick access
to the violation results

After installing a plugin and setting up your project, you should run a code analysis just by clicking the option from the menu NDEPEND => Analyze => Run Analysis or moving de mouse over a circle in the notification bar and click in Run a First Analysis on this NDepend Project.

If you move the mouse again - once the analysis finished - over the circle in the notification bar you should see the Code Queries and Rules Summary, with fast access to the Critical and Rules Violated. 

Such results, categorized into Code Quality, Object Oriented Design, Design, Architecture, Layering, Dead Code, and so on, are displayed on the Query and Rules Explorer panel and allow us to navigate from the violation directly to the source.

Categorized violation query results on the Query and Rules Explorer

For instance, let me check from Code Quality category, the rule Methods with too many parameters - critical.  

The rule description is the following: Methods with more than 8 parameters might be painful to call and might degrade performance. You should prefer using additional properties/fields to the declaring type to handle numerous states. Another alternative is to provide a class or structure dedicated to handle arguments passing.

The analysis found 16 violations of this rule, by clicking it you can navigate to the method. In this case, I selected one with 9 parameters and found out that indeed, it must be refactored. Now, thanks to the integration of Visual Studio and Git,  you can also see who's the author of this violation. 

Navigating from rule 'Methods with too many parameters - critical' result to StartSiteCreationProcess method

Let me take a closer shoot to see who that is:

Oops!!! it's me, I need to fix this ASAP ;)

Conclusion

The important thing is, not to accumulate technical debt and fix it as soon as it is detected. For .NET developers, NDepend is the right tool to start with.

You can make mistakes (critical or not), but being aware of your code quality constantly makes the difference between the apparent and intrinsic quality of your sources and consequently your products; even when untrained eyes may only see the beautiful lamp.

Btw, It seems like I've got similar skills as a painter than as a software developer ;)