NDepend: First Impressions From a Static Analysis Newbie
NDepend: First Impressions From a Static Analysis Newbie
A tool that has recently come to my intention is NDepend, a static analysis tool for .NET. This article is a summary of my first impressions with NDepend.
Join the DZone community and get the full member experience.Join For Free
Sharing his pioneering insight on how organizations can transform their software development and delivery processes, Gary Gruver provides a tactical framework to implement DevOps principles in Starting and Scaling DevOps in the Enterprise. Get your free copy.
A tool that has recently come to my attention is NDepend, a static analysis tool for .NET. This article is a summary of my first impressions with NDepend.
Disclaimer: My licence for this product was supplied by NDepend, but this is an unbiased review based on my usage so far.
What Is Static Analysis?
Static analysis is the analysis of your code. It is performed without running the code, hence static, and will report on things such as:
- Code style.
- Project dependencies.
- Code contracts.
- Best practices
Getting Started With NDepend
There is some great documentation out there to get you up and running with NDepend. The getting started section of their website is a great place to start. There is also a Pluralsight course, which I found to be useful.
Once NDepend is installed, everything can be accessed through the NDepend toolbar option in Visual Studio.
NDepend gives you insights into the health of your code base as a whole. Often, we look at our code at a class level. NDepend lets you see the bigger picture. From that, you can make informed decisions on a variety of things ranging from architecture to code quality to unit test coverage. There is a lot you can analyze with NDepend, and it can be quite daunting to begin with, so I am going to cover my top features to look at as an NDepend newbie.
The dependency graph is a fantastic way to explore your code base and to get an understanding and overview of the project architecture. By default, the size of the box for the assembly is proportional to the lines of code. I like this feature, as I can immediately understand where the meat of the project is. If this was a project that I was looking at for the first time, I would know which assemblies contain the majority of the code.
It also displays the dependencies of the assemblies on each other. I ran this tool on an old project with an n-tier architecture. Straight away, the graph was able to show me that the web layer had a dependency on the data layer. This was an immediate code smell as the web layer should have only had a dependency on the business or domain layer. Having this kind of overview of your project is very useful and allows you to get an understanding that you wouldn't necessarily get from looking on a class-by-class basis.
As well as looking at the whole solution, you can drill down into projects and classes.
Code Rules and Code Queries
Select Rule > ViewExplorerPanel from the toolbar, and this will bring up a panel showing you an analysis based on predefined queries. These cover a range of things, such as Code Quality, Architecture and Layering and even Object Oriented Design. Each rule is displayed with an indicator of "OK," "warning," or "critical." Each rule violation is explained and double-clicking on the rule will open a side panel, where you will be able to see where the violation is in the code.
By default, there are around 200 queries and rules, which, as a newbie to NDepend, should be more than enough. Once you start to get more comfortable with this feature, you can write your own rules and queries using NDepend's CQLinq.
This is something I think is really useful. Trend monitoring. Some of the trend charts you will see by default on the NDepend dashboard are:
- Lines of code.
- Code rules violated and code rule violations (as a number).
- Code coverage by tests.
The charts are very useful when it comes to monitoring the quality of a project over time. As a project grows, you expect the lines of code to increase, but you want the test coverage and code rule violations to stay the same. I think these charts are really useful for quantifying tech debt work. It is important to be able to show to the business the outcome of your hard work, in a sprint for example.
Often, this can be difficult, so being able to show that you have reduced the number of lines of code by 5% after that big refactor, or improved test code coverage from 80% to 90%, allows you to show the value of your work in a quantifiable way. On the flip side, being able to see that a new feature increased the number of lines dramatically and also reduced the test code coverage is an early warning sign that maybe your project is heading in a direction that you do not want it to.
You can, of course, create your own custom charts as you progress with NDepend, but this is a good set to get you started.
I've been using NDepend for a few weeks now, and I am quite pleased with it. As a newbie to the scene, I was a bit daunted by the information overload because it gives you so much. But I have found that you can start using a few features and, as you get more confident, try others. This is certainly what I intend to do. Hopefully, I have shown you a few that are easy to use and understand. I'm most interested in the trend charts and see them as a really useful metric. What feature/tool do you find most useful? Tweet me yours @iambacon.
Published at DZone with permission of Colin Bacon , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.