Brian Hartsock's Blog

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.

Visual Studio confuses me, and it is slow. I wanted to find all the assemblies/projects that contained references to System.Web.Mvc. Instead of loading up Visual Studio, I just did this.

 gci -recurse -filter "*.csproj" | 
     ?{ select-string "System.Web.Mvc" -path $_ }

Faster than loading Visual Studio, I promise.

I have published the source of my Code Camp talk here. Check it out and post any questions.

Thanks to everyone who showed up for the NHibernate talk. It went really well and everyone had tons of great questions. Feel free to post feedback here, both positive and negative, so the next time I give this talk, it will be even better.

For those of you that just want a little more guidance on NHibernate, here are some good links:

• NH Forge
• NHibernate Documentation
• Fluent NHibernate
• S#arp Architecture
• NHibernate best practices

Also, thanks to the coordinators of Richmond CC. I had a great time.

What’s wrong with the following?

return s.CreateQuery("from CodeCamp c where c.Name = :name order by c.Name")
    .SetParameter("name", "test")
    .List<CodeCamp>();

return s.CreateCriteria<CodeCamp>()
    .Add(Expression.Eq("Name", "test"))
    .AddOrder(Order.Asc("Name"))
    .List<CodeCamp>();

There are string references to .NET properties. That is a no-no. If there is a typo, you get runtime errors and not compile time errors. Now, good tests would catch it, but if you want the absolute fastest way to catch typos, NHibernate.Linq is the way to go.

return (from camp in s.Linq<CodeCamp>()
          where camp.Name == "test"
          orderby camp.Name
          select camp).ToList();

With Linq, you get that compile time checking that is going to help you move a little bit faster and make your code more robust. Combine this with Fluent NHibernate and you have a solid solution. Your mappings still have to be correct of course, but these projects take two variables out of the equation and use the compiler as a safety blanket.