Skip to content

Measure coupling & cohesion (modular design)

Good modular design keeps coupling (how much a unit depends on others) low and cohesion (how well the parts of a unit belong together) high. Understand measures both, for object-oriented code and for plain C, so you can find the tangled modules that are expensive to change and track improvement as you restructure.

Built-in coupling & cohesion metrics

For classes, several structural metrics ship built in (visible in the Metrics Browser):

Metric ID Measures
Coupled classes (CBO) CountClassCoupled Classes this class is coupled to
Lack of cohesion (LCOM) PercentLackOfCohesion % of methods not accessing a given attribute
Base / derived classes CountClassBase, CountClassDerived Inheritance coupling
Max inheritance depth MaxInheritanceTree Depth in the inheritance tree

These are part of the object-oriented family described in What metrics does Understand have?; for what a high or low value tends to signal, see Interpret key metrics.

Plugin metrics for deeper modular analysis

Understand's metric plugins add the metrics a dedicated modular-design review wants — and several work on C as well as C++, not just object-oriented code:

  • Fan-in / fan-out — DirectFanIn/DirectFanOut and the transitive VisibleFanIn/VisibleFanOut per file: the coupling measure that applies to any language.

    Two different fan-in/fan-out families

    These count files that depend on (or are depended on by) a file, in any language. The similarly named CountInput/CountOutput (a.k.a. FANIN/FANOUT, informational fan-in) are per-entity instead — calling subprograms plus global variables read — and only for C/C++, C#, Fortran, and Java. Pick the family that matches the granularity you're measuring; the numbers are not comparable.

Enable these from the Plugin Manager; or write your own for an in-house formula.

How to use them

  1. Enable the plugins you want, then open Metrics → Browse Metrics to see them per entity.
  2. To find the units everything else leans on, rank entities by the metric (see Rank & compare entities by a metric). Most of these are fine to sort directly — especially the cached fan-in/fan-out metrics — but CountClassCoupled is the slowest of the built-in class metrics to compute on demand; if you're sorting or exporting it project-wide, use CountClassCoupledBatch instead — it pre-computes every class's value once rather than one at a time.
  3. Cross-check cohesion (PercentLackOfCohesion / LCOM4) — a unit with high coupling and low cohesion is the prime candidate to split.
  4. To see why a number is what it is: for fan-in/fan-out, Browse & export dependencies shows the actual edges and the references behind them. For CountClassCoupled, the Coupled Classes Metric interactive report lists exactly which classes — and which references — contribute to the count.

Coupling is a language-specific idea

What counts as a dependency differs per language — see What are dependencies & how are they determined? so you read fan-in/out for your language correctly.

Guide the restructuring

Use the numbers to target work — decouple the highest-fan-in modules, raise cohesion by splitting grab-bag files — then track the metrics across releases to prove modularity improved. See Refactoring at scale and Export & track metrics over time.

Where to next