Let’s Build a Metric 3: Compositeness
Last time, I talked through a little bit of housekeeping on the way to creating a metric that would be, uniquely, ours. Nevermind the fact that, under the hood, the metric is still lines of code. It now has a promising name and is expressed in the units we want. And, I think that’s okay. There is a lot of functionality and ground to cover in NDepend, so a steady, measurable pace makes sense.
It’s time now to start thinking about the nature of the metric to be created here, which is essentially a measure of time. That’s pretty ambitious because it contains two components: defining a composite metric (recall that this is a mathematical transform on measured properties) and then tying it an observed outcome via experimentation. In this series, I’m not assuming that anyone reading has much advanced knowledge about static analysis and metrics, so let’s get you to the point where you grok a composite metric. We’ll tackle the experimentation a little later.
A Look at a Composite Metric
I could walk you through creating a second query under the “My Metrics” group that we created, but I also want this to be an opportunity to explore NDepend’s rich feature set. So instead of that, navigate to NDpened->Metric->Code Quality->Types with Poor Cohesion.
When you do that, you’re going to see a metric much more complicated than the one we defined in the “Queries and Rules Edit” window. Here’s the code for it, comments and all.
// Types with poor cohesion
warnif count > 0 from t in JustMyCode.Types where
(t.LCOM > 0.8 || t.LCOMHS > 0.95) &&
t.NbFields > 10 &&
t.NbMethods > 10
orderby t.LCOM descending, t.LCOMHS descending
select new { t, t.LCOM, t.LCOMHS,
t.NbMethods, t.NbFields }
// Types where LCOM > 0.8 and NbFields > 10
// and NbMethods > 10 might be problematic.
// However, it is very hard to avoid such
// non-cohesive types. The LCOMHS metric
// is often considered as more efficient to
// detect non-cohesive types.
// See the definition of the LCOM metric here
// http://www.ndepend.com/Metrics.aspx#LCOM
There’s a good bit to process here. The CQLinq code here is inspecting Types and providing data on Types. “Type” here means any class or struct in your code base (well, okay, in my code base), along with a warning if you see anything that matches. And, what does matching mean? Well, looking at the compound conditional statement, a type matches if it has “LCOM” greater than .8 or “LCOMHS” greater than .95 and it also has more than 10 fields and 10 methods. So, to recap, poor cohesion means that there are a good number of fields, a good number of methods, and… something… for these acronyms.
LCOM stands for “Lack [of] Cohesion of Methods.” If you look up cohesion in the dictionary, you’ll find the second definition particularly suited for this conversation: “cohering or tending to cohere; well-integrated; unified.” We’d say that a type is “cohesive” if it is unified in purpose or, to borrow from the annals of clean code, if it conforms to the single responsibility principle. To get a little more concrete, consider an extremely cohesive class.
public class Recipe
{
private List _ingredients = new List();
public void AddIngredient(Ingredient ingredient)
{
_ingredients.Add(ingredient);
}
public void StartOver()
{
_ingredients.Clear();
}
public IEnumerable GetAllIngredients()
{
return _ingredients;
}
}
This class is extremely cohesive. It has one field and three methods, and every method in the class operates on the field. Type cohesion might be described as “how close do you get to every method operating on every field?”
Now, here’s the crux of our challenge in defining a composite metric: how do you take that anecdotal, qualitative description, and put a number to it? How do you get from “wow, Recipe is pretty cohesive” to 0.0?
I originally wrote this post for the NDepend blog. Click here to read the rest and hear me talk about going from qualitative to quantitative.
