NDepend your guide to Kaizen your codebase

From time to time I have used a tool called NDepend to help me analyze the codebase I have been working on. Most of the times in the past I have been working in codebases where I was part of the project from the beginning or near its inception. This time I get to work on a codebase that has been developed for a few years and most of the people who started the development is long gone.

CQL the Sensei that let you find your way

When working with code I always try to follow “The Boy Scout Rule” and leave the code in a better state than when I started. I usually do this by refactoring and cleaning up when I touch the code for specific reason like a change request or bug fix. But some times you gets some slack or have quality improvement time scheduled. When this happens how do you know what part to go work on first? You need someone to guide you.

This is the area where NDepend really shines. NDepend really is like a Sensei that shows you the way. There are the standard reports and you get things like:

• Methods with the most lines of code
• Methods with the highest cyclomatic complexity
• Methods with the most parameters
• Methods with too many local variables

And the list goes on and on. The amazing and greatest thing however is that theses reports are not static. The reports are built with CQL – Code Query Language. This is more or less like having a SQL database that you can query, but the database is your codebase! In my case I needed to modify the most lines of code query to exclude the “InitializeComponent” method to see what methods to look into.

Here is the CQL query I used and the result(method names renamed to protect the guilty ):

SELECT TOP 10 METHODS
WHERE !(NameLike “InitializeComponent”)
ORDER BY NbLinesOfCode DESC
methods	# lines of code (LOC)
MethodName1	424
MethodName2	401
MethodName3	383
MethodName4	340
MethodName5	303
MethodName6	301
MethodName7	292
MethodName8	265
MethodName9	262
MethodName10	257
Sum:	3 228
Average:	322.8
Minimum:	257
Maximum:	424
Standard deviation:	57.844
Variance:	3 345

Here is one of the standard queries that gives me the most complex methods.

// <Name>Methods too complex (CyclomaticComplexity)</Name>
WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE
CyclomaticComplexity > 20
ORDER BY CyclomaticComplexity DESC
methods	Cyclomatic Complexity (CC)	Full Name
Method1	147	Assembly.Class.Method1
Method2	125	Assembly.Class.Method2
Method3	119	Assembly.Class.Method3
Method4	118	Assembly.Class.Method4
Method5	107	Assembly.Class.Method5
Method6	103	Assembly.Class.Method6
Method7	92	Assembly.Class.Method7
Method8	91	Assembly.Class.Method8
Method9	88	Assembly.Class.Method9
Method10	88	Assembly.Class.Method10
Sum:	1 078
Average:	107.8
Minimum:	88
Maximum:	147
Standard deviation:	18.443
Variance:	340.16

With the standard reports and CQL I have Sensei that guides me in my Kaizen work on the codebase.

Visualize your codebase

Queries and tables with the results are very useful but with NDepend you can go to the next level by visualizing you codebase.

This visualization shows the number of lines of code per method in all classes analyzed. It is very easy to spot the problem areas in the codebase.

 

This is another diagram that help me spot potential problem areas of the codebase.

NDepend is really a great tool to give you a feel for your codebase and where your focus areas for you code Kaizen should be. Give it a try.  

Two previous post related to this topic:

• Code Metrics, the Weight Watches Points system for code improvements
• Code Metrics, the numbers are not the point

Code Metrics, the numbers are not the point

When using different kind of code metrics it is important to understand that the actual numbers are almost never the main point. Code metrics should be used to see trends and areas of interest not as absolute goals. The numbers should be the catalyst for reaching the business goal. Sometimes the absolute numbers will lead you to miss the actual business goal.

In my previous post I talked about “The Boy Scout Rule”. An easy way to measure adherence to “The Boy Scout Rule” for the amount of code with unit tests are the code coverage metric. The actual test coverage number tells you what lines of code has been covered by unit tests and that is all and well. But more interesting is if you are increasing or decreasing code coverage between check-ins. High code coverage is in general good (to a point) but the more important is your goal to continuously increase that code coverage(to a point) for every check-in and not going the other way around.

Another interesting code metric is Cyclomatic complexity. In short it measures the number of paths thru a piece of code. You can use this code metric to locate methods and classes in you code base that are probably complex and therefore is harder to maintain and could be candidates for refactoring.  Use Cyclomatic complexity to remove accidental complexity from you code base. The problem thou is that complexity is not always accidental but inherent to the problem you try to solve so you can’t use absolute numbers when using Cyclomatic complexity. Aggregating the Cyclomatic complexity and trending it over time and you can see if you are a good complexity reduction boy scout or not.

There are lots of other interesting code metrics that you can use and a tool I really like is nDepend. There are lots of different built in metrics and you can create your own using CQL (SQL for code).

One big problem I find in most .Net code bases are the amount of business logic in the code behind classes for WinForms and WebForms applications. It is not always easy to make developers change their coding behavior especially if they have a large code base with this problem. You can try to explain all the problems with this coding style and the benefits of separating the presentation code from the business logic. You will probably fail. I think a better way is to slowly coach the developers using code metrics and good examples.

If you have nDepend you can easily add a CQL query to you build that gives you the classes that has the most lines of code in the code behind.

SELECT TYPES WHERE

DepthOfDeriveFrom  "System.Windows.Forms.UserControl" > 0

OR DepthOfDeriveFrom  "System.Windows.Forms.Form" > 0

AND NbLinesOfCode > 200

ORDER BY NbLinesOfCode DESC  

Aggregate the number of lines of code and then trend this over time you have a code metric for the state of your code behind code.

If using this kind of metric you can start to make your developers change their behavior by giving strong positive feedback when they are trending in the right direction. Hopefully then it will be easier over time to have discussions about the pro and cons of the mix of business and presentation code.

It is not the actual numbers, but the trend that is the point.

Code Metrics, the Weight Watches Points system for code improvements

A few years ago I was trying to improve my road bike riding skills for a 300 km long bike race called Vätternrundan. I was, to be kind, overweight. I had tried for some years to lose some weight but always faltered with my motivation. It always felt like it was too many kg to lose to really get started so I never made a real effort. I didn’t believe in Weight Watches and other weight loss programs but my wife convinced me to try it. I got a correspondence program and started reading the material. Nothing really appealed to me and I still felt like the task was overwhelming. But I started to keep the diary as suggested. I followed the program but ate a few points over the recommendation and felt quite bad about it. I kept up updating the diary and I started to trend my points intake and my weight. Low and behold, two weeks in I had lost 2kg! My motivation grew and I started to look at the points intake and weight loss trends avidly.  20 weeks later and I had lost 26kg!

So can you use the same kind of motivation for code improvements? Yes I think so.

For years I have tried to apply “The Boy Scout Rule”, formulated by Uncle Bob (Robert C Martin), on my code base:

 “Always check-in a module cleaner than when you checked it out."

If you follow this rule your code base should little by little become better and the problems will wither away over time just like my weight loss. If you have a large code base with lots of problems it can feel like an insurmountable task to fix all the problems and you push the change off. Maybe you say, next major change request I will rewrite it without the problems. But there is very seldom the time or the money too really do a full rewrite so you keep pushing it off. What if we could use Code Metrics to motivate code improvements the same way as Weight Watches use the Points system for motivating weight loss?

I believe you can use Code Metrics to motivate developers to follow “The Boy Scout Rule” in their code base.

In coming posts I will illustrate how to use code metrics and visual tools to keep developers motivated for continuous code improvements.