It has been quite some time since we looked at the NDepend tool (http://www.ndepend.com/). We remember reading a Robert C. Martin book and were enthusiastic about his ideas about assembly dependencies. Back then, we were pleasantly surprised to find out that there was a tool based on the ideas of Robert C. Martin, and did some experimenting with it, but for some reason the tool didn’t quite fit in our development process.
Recently, we took another look at the tool and were pleasantly surprised by the way it has evolved. It has been designed to participate in Continuous Integration (CI) scenarios, has become a full-blown code analysis tool including nice reporting capabilities, and the documentation and ease of use are top notch. The feature we like best of all is the little amount of effort it takes to create your own code rules, something we have really want for some time and found to be lacking in the standard Visual Studio Static Code analysis features.
Let’s take a moment to discuss some of the other features…
- There’s a visual tool that allows you to inspect NDepend projects (that analyze your own VS projects) without having to start Visual Studio separately.
- There’s a console tool that ios ideal for CI purposes.
- There’s a VS add-in(also support VS 2012) allowing easy access to NDepend features:
- The Queries and Rules explorer performs static code analysis of your code:
- The tool is shipped with nice reporting capabilities:
- You can run Linq queries live at design time to inspect the code base you’re working with:
- The Dependency Graph is impressive:
- Great in-context info. In the example below we use NDepend to find out which methods are using the current method:
- NDepend allows you to Diff separate versions of source files and highlights the differences ( http://www.ndepend.com/Doc_VS_Diff.aspx )
- Of course, the unique Robert C Martin package dependency report isn’t missing, and luckily our PressurePoint is doing wonderful:
The tool is packed with handy features:
As said before, our favorite feature is the ability to quickly create new code rules. You can do this just by using some Linq code and learn from the examples. For instance, the next code rule checks for methods that are considered to be too big:
// <Name>Methods too big</Name>
warnif count > 0 from m in JustMyCode.Methods where
m.NbLinesOfCode > 30 ||
m.NbILInstructions > 200
orderby m.NbLinesOfCode descending,
m.NbILInstructions descending
select new { m, m.NbLinesOfCode, m.NbILInstructions }
// Methods where NbLinesOfCode > 30 or NbILInstructions > 200
// are extremely complex and should be split in smaller methods.
// See the definition of the NbLinesOfCode metric here
// http://www.ndepend.com/Metrics.aspx#NbLinesOfCode
This rule checks method access modifiers:
// <Name>Methods that could have a lower visibility</Name>
warnif count > 0 from m in JustMyCode.Methods where
m.Visibility != m.OptimalVisibility &&
!m.HasAttribute(“NDepend.Attributes.CannotDecreaseVisibilityAttribute”.AllowNoMatch()) &&
!m.HasAttribute(“NDepend.Attributes.IsNotDeadCodeAttribute”.AllowNoMatch()) &&
// If you don’t want to link NDepend.API.dll, you can use your own attributes and adapt this rule.
// Eliminate default constructor from the result.
// Whatever the visibility of the declaring class,
// default constructors are public and introduce noise
// in the current rule.
!( m.IsConstructor && m.IsPublic && m.NbParameters == 0) &&
// Don’t decrease the visibility of Main() methods.
!m.IsEntryPoint
select new { m,
m.Visibility ,
CouldBeDeclared = m.OptimalVisibility,
m.MethodsCallingMe }
Finally an easy way to implement code rules specific to our own projects. All in all, we’re happy with our brand new toy! If you want to take it for a test spin you can get it here: http://www.ndepend.com/NDependV4.aspx.
SharePoint Dragons 