What Are the Chidamber & Kemerer Metrics?
The Chidamber & Kemerer (CK) metrics suite, introduced in 1994, remains one of the most widely used frameworks for measuring object-oriented software quality. Originally designed for any OO language, the suite maps naturally onto Java and forms the backbone of tools like CKJM, which calculates these metrics directly from compiled Java bytecode.
The suite defines six core metrics, each targeting a distinct quality dimension of a class or system. Understanding what each one measures — and what thresholds signal trouble — is the first step toward actionable quality improvement.
The Six Core CK Metrics Explained
1. WMC — Weighted Methods per Class
WMC sums the cyclomatic complexity of all methods in a class. A class with many complex methods is harder to understand, test, and maintain. When WMC climbs above 50, it's a strong signal that the class is doing too much and should be split.
2. DIT — Depth of Inheritance Tree
DIT measures how deep a class sits in the inheritance hierarchy. Deeper hierarchies reuse more inherited behavior but make it harder to predict a class's full behavior. A DIT above 5 typically indicates over-engineering of the inheritance structure.
3. NOC — Number of Children
NOC counts the direct subclasses of a class. A high NOC means a parent class has broad influence; a change to it propagates widely. While inheritance is powerful, a parent with many children demands careful design and thorough testing.
4. CBO — Coupling Between Object Classes
CBO counts how many other classes a given class depends on. High coupling makes classes hard to reuse and test in isolation. Keeping CBO low is one of the most impactful ways to improve modularity.
5. RFC — Response for a Class
RFC measures the number of methods that can potentially be executed in response to a message received by an object. It includes the class's own methods plus all methods called by them. A large RFC means a class is harder to test and comprehend fully.
6. LCOM — Lack of Cohesion in Methods
LCOM quantifies how unrelated the methods of a class are to each other, based on which instance variables they access. A high LCOM score often means a class has multiple unrelated responsibilities and should be decomposed.
Interpreting Results: A Quick Reference
| Metric | Low (Good) | Medium (Watch) | High (Refactor) |
|---|---|---|---|
| WMC | < 20 | 20–50 | > 50 |
| DIT | < 3 | 3–5 | > 5 |
| NOC | < 5 | 5–10 | > 10 |
| CBO | < 10 | 10–20 | > 20 |
| RFC | < 50 | 50–100 | > 100 |
| LCOM | 0 | 1–3 | > 3 |
How to Run CKJM on Your Project
- Compile your Java project to produce
.classfiles. - Download the ckjm JAR from the project repository.
- Run:
java -jar ckjm.jar *.class > metrics.txt - Parse the output — each line contains the class name followed by WMC, DIT, NOC, CBO, RFC, and LCOM values.
- Sort by the metric of concern to find your worst offenders first.
Using Metrics as a Starting Point, Not a Verdict
Metrics are indicators, not absolute judgments. A high WMC in a well-tested utility class may be acceptable; a high CBO in a core domain object is almost always a problem. Always combine metric data with code review and domain knowledge before deciding what to refactor.
The real power of the CK suite is in tracking trends over time. Running CKJM on every build and visualizing the results lets you catch quality degradation before it becomes a crisis.