Tweaking the NDepend CQL rules to leverage awesome power

I have previously written about automating and scheduling NDepend for a set of .NET solutions.

After getting into the habit of using NDepend to find code issues instead of going through the code by hand (which I still will do, but a little help does not hurt), the power of CQL grows on me.

For instance, one big problem that I have wrestled with is that our legacy code contains static fields for non-static-should-be properties. In web context. Enough said.

Prior to using CQL, I used to search for “static” for the entire solution, go through the search result (which, naturally, also included fully valid static methods and properties) and…well, it really did not work.

Yesterday, when digging into the standard CQL rules to get a better understanding of the NDepend analysis, I noticed the following standard CQL:

// <Name>Static fields should be prefixed with a 's_'</Name>
WARN IF Count > 0 IN SELECT FIELDS WHERE 
 !NameLike "^s_" AND 
 IsStatic AND 
 !IsLiteral AND 
 !IsGeneratedByCompiler AND 
 !IsSpecialName AND 
 !IsEventDelegateObject 

// This naming convention provokes debate.
// Don't hesitate to customize the regex of 
// NameLike to your preference.

Although NDepend’s naming conventions do not quite fit my conventions, this rule is just plain awesome. I just had to edit the CQL to

// <Name>Static fields should not exist...mostly</Name>
WARN IF Count > 0 IN SELECT FIELDS WHERE 
 IsStatic AND 
 !IsLiteral AND 
 !IsGeneratedByCompiler AND 
 !IsSpecialName AND 
 !IsEventDelegateObject 

// This naming convention provokes debate.
// Don't hesitate to customize the regex of 
// NameLike to your preference.

and voilá – NDepend will now automatically find all static fields within my solution…and ignore any naming convention.

Since this got me going, I also went ahead to modify the following rule

// <Name>Instance fields should be prefixed with a 'm_'</Name>
WARN IF Count > 0 IN SELECT FIELDS WHERE 
 !NameLike "^m_" AND 
 !IsStatic AND 
 !IsLiteral AND 
 !IsGeneratedByCompiler AND 
 !IsSpecialName AND 
 !IsEventDelegateObject 

// This naming convention provokes debate.
// Don't hesitate to customize the regex of 
// NameLike to your preference.

to instead require that fields are camel cased (ignoring the static condition as well):

// <Name>Instance fields should be camelCase</Name>
WARN IF Count > 0 IN SELECT FIELDS WHERE 
 !NameLike "^[a-z]" AND 
 !IsLiteral AND 
 !IsGeneratedByCompiler AND 
 !IsSpecialName AND 
 !IsEventDelegateObject

Two small changes to the original setup, but awesomely helpful. Another great thing is that when you edit the queries in VisualNDepend, you get immediate, visual feedback to how the rule applies to the entire solution.

So, now I can start tweaking the standard CQL rules to that they conform to my conventions. However, when looking at the two rules above, where my versions should apply to all future NDepend projects that I create from now on, is there some way to globally replace the standard CQLs with my alternatives?

I will investigate this further and write a blog post if I happen to solve it.

Advertisements