Suggested thresholds for some software metrics

I was searching the internet for some suggestions for thresholds for the following well-known software product metrics:

• Lack of Cohesion in Methods (for the Henderson-Sellers variant of the metric)
• Number of Inherited Methods in a Class
• Number of Overriden Methods in a Class
• Number of Newly Added Methods in a Class

However I failed to 开发者_JAVA百科find any. I am particularly interested in the first one. Does anybody know something about this ? Thanks in advance, Martin

---

NDepend suggests the following:

http://www.ndepend.com/Metrics.aspx#LCOM

---

This reference gives for values for LCOM and LCOMHS. It says

• LCOM = 1 – (sum(MF)/M*F)
• LCOM HS = (M – sum(MF)/F)(M-1)

Where:

• M is the number of methods in class (both static and instance methods are counted, it includes also constructors, properties getters/setters, events add/remove methods).
• F is the number of instance fields in the class.
• MF is the number of methods of the class accessing a particular instance field.
• Sum(MF) is the sum of MF over all instance fields of the class.

The underlying idea behind these formulas can be stated as follow: a class is utterly cohesive if all its methods use all its instance fields

I'm not sure how well this measure works when dealing with a Java Bean, which could well have a large number of getters and setters each dealing with a single property.

---

Be aware that there is a lot of variability in the numbers produced by various tools for the "same" metric. Sometimes this is because the original source was imprecise and sometimes it is because the tool maker "improved" the metric. Most metric tools have a default threshold. I'd use that unless you have a strong reason not to.

I do a lot of cohesion measurement for large classes. I don't think I have ever seen an LCOM-HS measurement above 1.0, but I think you may see them for tiny classes (where you probably don't really care that much about cohesiveness). Personally, I use a threshold of 0.8, but that's arbitrary. I've read a lot of papers about cohesion, and I have seen very few thresholds mentioned. This includes the Henderson-Sellers papers that I've read.

djna is correct when he says that cohesion measures will give poor scores for JavaBeans and other "data storage" classes. Furthermore, many cohesion measurements, including LCOM-HS do not consider some things that may lead to misleadingly poor scores. For example, many implementations don't consider relationships with inherited members. LCOM-HS and many others also have an over-reliance on how methods access fields. For example, if you write a class where the methods mainly interact with "data" through their arguments, you will get what appears to be a highly non-cohesive class; whereas in reality, it may be well-designed.

In terms of the other metrics you mentioned, I've seen no recommendations. I've looked around, and the only recommendation I've seen pertaining to the number of XXX methods is a maximum of 20 per class (no detail as to instance vs. static, overridden, etc.).

Here is a list of some papers dealing with OO metrics, mostly cohesion.