Developing software is not just hacking in a solution, but to develop simple, well structured and therefore maintainable constructs. There are a couple of design guidelines that one should follow (
some of them are here) to achieve this. However often special time pressure or older code may nevertheless get messy and complex. That's where
refactoring comes in. Usually the best advice is to refactor immediately once you find
"smelling" code (as the XP guys call it). Don't postpone it to a later point, you won't come back.
What I found quite useful in finding points for refactoring is to use code metrics. Code metrics usually appear when software quality management comes into play and there exist really a bunch of different (more and less discussed) metrics. From my point of view the most interesting is the
Cyclomatic Complexity measure and the following two, "
Coupling between objects (CBO)" and "
Lack of cohesion in methods (LCOM)" from the CK suite (Chidamber and Kemerer OO measures).
Why do I point out especially these three? Well, because they are easily understandable and they point out problems in the design of your code, usually at class level. For instance:
- Cyclomatic Complexity
It measures the complexity of parts of your code and is calculated by counting the number of decision points + 1.
public bool checkSomething(int x){
bool result = false;
if(x < 10)
result = true;
else
result = false;
return result;
}
This extremely simple piece of code has CC = 2 because we have one decision point (the if). But just changing the code in this way...
public bool checkSomething(int x){
bool result = false;
if(x < 10){
if(x > 4)
result = true;
else
result = false;
}else{
result = false;
}
return result;
}
...increases the cyclomatic complexity already to 3 etc. And you see, it is already more difficult to read because you have to check carefully which kind of x values would now go through the first branch and result in a "true" value, which in a "false" value and which would immediately skip the first branch and result in a "false" value. Normally a value below CC=10 is considered to be acceptable, although I usually try to keep it below 6-8. Imagine however how a code would look with CC = 20 and higher. And how hard it would be to debug it.
Of course you don't have to calculate these things by hand :) . There exists tools for nearly every IDE. In Visual Studio Team system for instance you can calculate such metrics by using the context menu in the Solution Explorer.
The results will then be displayed in the Code Metrics Results view. The MSDN Code Analysis blog explains the Visual Studio code metrics view and its calculated metrics in more detail
here.
Questions? Thoughts? Hit me up
on Twitter
