Create NDepend rules with technical debt
Following the article on technical debt in NDepend, I thought it would be good to show that you can create yourself custom rules with a value for technical debt.
NDepend uses CQLinq to create its own rules. The language is based on the Linq (who would have though?), so it is familiar.
As example, I will create a rule that checks at if there are no async methods that return void (Bad!). With the exception of the event handler methods because there is no way around that. I’ll consider as event handler method the ones that have an object and a derived type of eventargs as a parameter (Yes, this is not 100% reliable but almost).
First, I wrote a class with 2 cases, to see if the rules works:
Here you go. Now in NDepend, I go in the menu NDepend, Rules, New, Code Rule.
That’s the rule code:
Here’s what the code does:
- It takes all types that derive from EventArgs (+ EventArgs itself), and creates a list of strings of format “(Object, EventArgType)”. It will be used to make a match with the full name of the method that is returned in the format “MethodName(typeparam,…). It seems unnecessarily complicated, but it is because there is no way to make queries on the parameters of a method in CQLinq, so we need this kind of manipulation.
- I put in a variable the Void type, that will be used during the request.
- It seeks all the async methods that return void but who, if they have two parameters, do not have an event handler signature.
- For all of these methods, it returns an object with the method, but also a value for the debt (the time it takes to fix it), and also set an annual value that represents the annual cost of not fixing it.
I also clicked on the button “Critical” so it becomes a critical rule (to be sure to have many red on dashboard!)
And you see, the query selects the classic method, but not the one with the signature type event handler, as expected
And if we compare the before NDdepend report
It shows the debt has increased by 20 minutes and the annual part of 2 h, which corresponds to what the rule refers to each method found (in our case, only one)!
As you can see, it is quite easy to add your own rules and add an estimation of the technical date.
Note that CQLinq can be used to make queries on the code, without making a rule. If you want to know how many methods with more than 3 parameters, how many properties on average per class, etc… you can write a query for that.