Ensure the quality of the code that will be developed this year

Do a favor to yourself and your team: Make sure that the code you will develop in 2008 will abide by common quality principles.

The classic blame on quality tools I hear again and again is: When the tool analyzes my code base, it yields literally thousands of warnings. I don’t have the time to go through all these problems.

Actually, this blame is similar to the one that is made against automatic tests. I don’t have the time to stop my development for months just to code unit tests on existing code. There is one simple answer to this situation apparently widely accepted amongst the agile experts: from now, make sure that all the code you are doing or refactoring will be unit tested.

I propose the same answer for code quality: from now, make sure that all the code you are doing or refactoring will abide by common quality principles. And now comes the tricky part: how can I specify to my quality tool which part of my code base is new or has been refactored?

NDepend and its ability to write code rules and queries over LINQ (CQLinq) are able to compare 2 versions of a code base. The idea is then to regularly check that the quality will be respected on the code that has been changed since today. Concretely, you just have to write:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
// <Name>From now, all methods added or refactored should respect basic quality principles</Name>
warnif count > 0 from m in JustMyCode.Methods where
 
// *** Only new or modified methods since Baseline for Comparison ***
(m.WasAdded() || m.CodeWasChanged()) &&
// Low Quality methods// Metrics' definitions
( m.NbLinesOfCode > 30 || // http://www.ndepend.com/Metrics.aspx#NbLinesOfCode
m.NbILInstructions > 200 || // http://www.ndepend.com/Metrics.aspx#NbILInstructions
m.CyclomaticComplexity > 20 || // http://www.ndepend.com/Metrics.aspx#CC
m.ILCyclomaticComplexity > 50 || // http://www.ndepend.com/Metrics.aspx#ILCC
m.ILNestingDepth > 4 || // http://www.ndepend.com/Metrics.aspx#ILNestingDepth
m.NbParameters > 5 || // http://www.ndepend.com/Metrics.aspx#NbParameters
m.NbVariables > 8 || // http://www.ndepend.com/Metrics.aspx#NbVariables
m.NbOverloads > 6 )
select new { m, m.NbLinesOfCode, m.NbILInstructions, m.CyclomaticComplexity,
m.ILCyclomaticComplexity, m.ILNestingDepth,
m.NbParameters, m.NbVariables, m.NbOverloads }
view raw gistfile1.cs hosted with ❤ by GitHub

The conditions (m.WasAdded() || m.CodeWasChanged() can be understood as Code that has been refactored or new code.

The NDepend project can be easily configured to define with which previous analysis the comparison will be made against. The following screenshot shows how to specify a particular analysis, made on the 27th March 2007. You can also compare against an analysis made N days ago or the last analysis done.

Here are 10 essential quality rules I would suggest. 

This entry was posted in CC, Change summary, Changes, Code Diff, Code Query, Code Rule, CQLinq. Bookmark the permalink. Follow any comments here with the RSS feed for this post.