Some time ago I blogged (here and here) about Needle , a dependency injection container I used to work on when procrastinating. As I’m planning to spend some time working on updates I thought it would be a good idea to use NDepend 4 and get a sense of possible improvements I could tackle before getting to work on the new features.
I had not used NDepend 4 before (I did have some experience using previous version of NDepend) and of course the feature that I found the coolest was Code Query over LINQ. The query editor definitely makes things easier for users, as it provides code completion and error description which combined with the fact that you get all the LINQ goodness allows you to create your queries in a really fast and easy manner.
As soon as I created the NDepend project to go over the solution, the default rule set was compared against my code (and I got 0 reds 
). As you can see in the following figure, there are a lot of different categories. I like to think of them as belonging two main areas, those that affect the how clients of my library will interact with it (particularly important for a DI container) and those that affect the code itself (maintainability, dependencies).
For the first area for example, one of the warnings I got was related to the immutability of property getters. As you can see the rule does a great job of taking advantage of the properties exposed by the query objects by simplifying fairly complex concepts such as state changes with the usage of properties like ChangesObjectState and ChangesTypeState. Another good thing is that it provides an explanation so you can determine whether that violation is something you are OK with or not. In the get_FactoryMethod() case the factory is created lazily so that is a rule violation that I consciously decide to live with.
Another really important find was related to the invocation of virtual methods in constructors. That is something I don’t usually miss but I my plea is non-guilty as the method was declared in an interface and the class is not supposed to be inherited from. Nevertheless, the discovery is definitely useful as I sealed the class thanks to it.
For the latter area, there are some really useful rules such as one that allows you to find dead methods. As always, you must use a critical judgment when interpreting these results. For example, all the methods that appeared in the list are invoked through reflection (to create generic types dynamically).
I haven’t come up with a custom rule I want my code to be compliant with yet, but I still wanted to see how hard it would be to create one. I immediately recalled that my old teammate Diego Geffner always used to mention that he worked at a company that enforced a maximum 7 lines per method policy. This is what the rule looks like (I’m more of a LINQ extension methods guy):
Amazingly having developed without that rule in mind only 10 out of 240 methods were detected as offenders.
As you can see the ability to create custom rules using all the power and flexibility of Code Query over LINQ is definitely a tool worth considering to enforce common practices among all developers in a project or company. I believe that the fact that they are easy to write and understand is also a major plus as each team/developer can create their own subset to suit their particular needs, leveraging all their existing LINQ knowledge.