Seeing Trends in Code Metrics with NDepend

Question

I have a version of NDepend for build servers and have automated the NDepend report generation. So, every night the build does its thing and NDepend reports/XML are generated. What I now want to do is track some metrics as a function of time.

So, for instance, it might be nice to have a graph of a particular type or namespace's, say, afferent coupling, on the y axis with time on the x axis. I know that I can compare two NDepend builds and have code and metric diffs, but what I'm looking to do is compare the same single metric or metrics over N builds to see ongoing trends.

I'm sort of assuming that there isn't a tool that does this currently and that I'll have to roll my own, but if there is one out there, I'd sure love to hear about it before investing the time. So, does NDepend itself support anything like this, or is there some sort of utility that already exists that I could use?

I'm also open to suggestions for other technologies that would accomplish this besides NDepend, though I have a strong preference for NDepend due to already having invested in it and being familiar with how it works.

Thanks in advance.

Answer 1

With NDepend, you can write a Code Query over LINQ (CQLinq) to match evolution through any code metrics. For example you could start with the query:

from t in JustMyCode.Types
where t.IsPresentInBothBuilds() &&
      t.CodeWasChanged()
let tOld = t.OlderVersion()

let newLoC = t.NbLinesOfCode  
let oldLoC = tOld.NbLinesOfCode
let newCC = t.CyclomaticComplexity
let oldCC = tOld.CyclomaticComplexity
let newCov = t.PercentageCoverage
let oldCov = tOld.PercentageCoverage
where newLoC > oldLoC || newCC > oldCC || newCov < oldCov
select new { t, newLoC, oldLoC, newCC, oldCC, newCov, oldCov }

...and get an instant result in Visual Studio. Such rule is integrable into your CI TFS build process and can also be shown in a HTML+javascript report.

Several default code rules are provided to restrict over code metric trending:

• Avoid making complex methods even more complex
• Types that used to be 100% covered but not anymore
• From now, all types added or refactored should respect basic quality principles
• Avoid adding methods to a type that already had many methods
• Avoid making large methods even larger