Last night, I spent a good amount of time with NDepend on one of my largest projects. I have seen NDepend before, but never used it myself. These are my thoughts on using it, and hopefully the first of many posts about how it has made my projects better.
How to get started?
The first step was selecting all the assemblies to analyze. This actually wasn’t as easy as I thought, but it was really due to my project setup and not NDepend. When you add a Visual Studio solution to NDepend, it will show warnings and errors that it sees from the project DLLs. I had three main issues to solve.
One, I had a few projects unloaded in the solution, which meant they had stale binaries in their build folders. This confused NDepend, so I loaded the projects, rebuilt, and fixed it.
Second, System.Web.Mvc wasn’t found. This was an interesting issue where I had to set “Copy Local” true to the System.Web.Mvc reference. Not entirely for sure why, but it fixed the error.
Finally, NDepend helped me catch a very odd problem, using different versions of an assembly. I had a few projects referencing a new version, while the other projects referenced an old version. I have no idea how this happened, but I was glad to catch it.
Now, I was ready to analyze.
Where to begin?
NDepend spews out a crazy amount of information. It is really hard to know where to get started. My advice, especially on a large project where you are running NDepend for the first time, close the dependency matrix, graph, and metrics views. Start with the CQL queries.
Why? Because they are easier to understand and have clear solutions (for the most part).
Here is how I immediately improved my project, without reading a single sentence of documentation. First, I looked at the unused types warning. I removed 5 classes that weren’t use, which is probably the most exhilarating feeling.
I also really liked how it called out generic exceptions being thrown. All too often, developers put place holder generic exceptions in the code, and never get around to creating custom exceptions.
Lastly, the code quailty queries are awesome. I love seeing warnings for code complexity, large methods, etc. These are the methods that can easily be refactored and make the code base a little easier for everyone to work with. Every query in code quality is solid.
What didn’t I like?
I think NDepend has a high learning curve. It throws a lot of info at you and you are responsible for figuring it out. During my first look, I didn’t bother with most of the complex functionality. Even with CQL queries, there aren’t easy-to-find reasons why some of the warnings even exist. Here is an example, why is List.Contains() worth warning? I am not entirely for sure, so it makes me less prone to gain any value from this query.
One thing I quickly realized was I needed an easy way to ignore collecting metrics on certain types. For example, I have a lot of web services with generated code. I wanted to ignore most of these classes for the report. I couldn’t find an easy or quick way to do it.
Final thoughts
The one thing I realized after getting started with NDepend is that it is up to the user how valuable it is. Just like code quality and testing is a commitment, so is using NDepend. It won’t solve all your problems out of the box, but if you want help analyzing your codebase so you can improve it, NDepend is your tool.
For me, I think I can learn a lot from using it, although I should probably start on a smaller project and work my way up.