Let’s talk about code metrics for a second.  It’s not something that is typically tracked by development teams, but here’s why you should.  Gathering code metrics can give you valuable insight into the testability and structure of your code.  By monitoring a few key metrics you can spot places where your code may need to be refactored.

Tools:

Let’s start with a free tool named Source Monitor.  There are lots of tools out there, but this one will do the job.  Essentially what you do is point the tool at a directory containing your source and the tool extracts all kinds of information for you.  I’ll let you go through all the bells and whistles on your own time.

The Metrics:

I personally like the Kiviat graph provided by Source Monitor because it displays a quick overview where your metrics are compared to your thresholds (These are configurable in the Options section). 

So what you say?  Let’s take a look at some of these metrics.  As you can see my test project’s metric for Max Complexity is outside of my threshold of 2-8.  So what’s a Max Complexity?  It measures the amount of code execution paths per method.  That’s right… All the If’s, Else’s, For each loops, etc.  Judging by how far it’s out of bounds there are probably some methods I need to consider refactoring to reduce the paths and make my code more testable!  Easy.  The same with Max Depth.  It measures the maximum block level depth.  clearly I’m outside the bounds I set.  The tool is configurable but you get the idea.

Still wondering so what?  I would take a look at this book review of the ThoughtWorks Anthology:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.
2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.
3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.
4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.
5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().
6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.
7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.
8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.
9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”

I’m not sure about you, but I’m always looking to do better OO. :)