I’m currently test-driving NDepend, a code analysis tool, and spoiler alert, I am very pleased with what I see! There’s a 3-minute video on their getting started page that goes over the install and more, including running your first analysis and deciphering the report (which can be very intimidating if you don’t know what it all means). If you plan on using NDepend then you need to look at the documentation; there’s a ton of it!
Now, there are already so many NDepend reviews on the web, and they are all great (some are a little dated), so I don’t want to go down the same road and say the same things. This is more for anyone that’s not familiar with the product and/or code analysis in general, and about how I use it. If you’re already familiar with NDepend feel free to minimize the next section and just continue your reading beneath it.
What does NDepend do?
You start out by running an analysis on your compiled assembly, which shows you the offending blocks of code. You can view the offenses with the Queries and Rules Explorer panel.
From here you can easily pick out what’s good and what’s bad by looking at the yellow warning icons in the pane on the left. When you click a group the pane on the right will populate with the violated rules for that group. Clicking on a violated rule will take you to the Queries and Rules Edit panel that shows you a drill-down view of all the violated rule instances.
But that’s just the beginning. Where NDepend really shines is with reporting and CQLinq! CQLinq, as hinted at above, allows you to create your own rules and guidelines for standardizing your code.
For example, if you wanted to see if any of your methods are over 45 lines of code you could use:
|
1 2 3 4 |
warnif count > 0 from m in JustMyCode.Methods where m.NbLinesOfCode > 45 orderby m.NbLinesOfCode descending select new { m, m.NbLinesOfCode } |
To be continued…
When I first started programming I would just spit out code and not really care about what was going on underneath. I don’t know when it happened but at some point I realized that all of that jumbled mess needed to be cleaned up and optimized. Fast-forward some years and now I can’t stop searching for best practices and optimizations (I know, I know…those two things are not always the same thing). The great thing about tools like ReSharper and NDepend is that I’m able to stand on the shoulders of programming giants. Tools like this help my code smell a little less…putrid. Using their violation rule-set I can quickly determine where I may be shooting myself in the foot. Plus, I can add my own violation rules in a matter of seconds and have them run against my code base automatically, on every compile!
I’ve only started a couple of new projects (I don’t mean test projects, I mean ones that will hopefully see the light of day) since I began using NDepend. And with each new project I analyze early and often. It helps keep my code smelling fresh and clean. I plan on doing another write-up on CQlinq. Until next time…
