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:
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.
- From now, all methods added or refactored should respect basic quality principles
- From now, all types added or refactored should respect basic quality principles
- From now, all types added or refactored should be 100% covered by tests
- Avoid decreasing code coverage by tests of types
- Types that used to be 100% covered but not anymore
- Avoid making complex methods even more complex (Source CC)
- Avoid making large methods even larger
- Avoid adding methods to a type that already had many methods
- Avoid transforming an immutable type into a mutable one
- Avoid adding instance fields to a type that already had many instance fields