What is a data clump and how does EK9 detect it?

← Code Quality · Ref: Q962

A data clump occurs when 3 or more callables share 4 or more parameters with the same types and names. EK9 detects this at compile time and raises E11053.

WHY THIS MATTERS

Repeated parameter groups signal a missing abstraction. Martin Fowler identified data clumps as a code smell in 'Refactoring' (1999). The repeated parameters should be extracted into a record.

THRESHOLD

- 4 or more parameters with matching types and names
- Shared across 3 or more callables in the same module

THE FIX

Extract a record:

  defines record
    Coordinate
      latitude as Float: Float()
      longitude as Float: Float()
      altitude as Float: Float()
      heading as Float: Float()
      default operator ?

Then pass the record instead of 4 separate parameters.

THIS EXAMPLE

Two functions share 4 Float parameters (latitude, longitude, altitude, heading). With only 2 functions sharing the clump, this is below the threshold of 3.

The typicalError mutation adds a third function with the same 4 parameters, triggering E11053.

WHY DATA CLUMPS ARE A PROBLEM

This is a DESIGN problem, not a technical one:
1. Maintenance burden: changing the group requires updating every callable that uses it
2. Missing abstraction: parameters that always travel together are a type waiting to be extracted
3. Inconsistency risk: one function might swap parameter order, causing subtle bugs
4. Testing complexity: 4+ parameters create a combinatorial explosion of test cases

See Q313 for code smells. See Q310 for quality overview.

Example

defines module qa.quality.dataclump

  defines function

    <?-
      Computes a distance metric from navigation coordinates.
      Uses 4 Float parameters: latitude, longitude, altitude, heading.
    -?>
    computeDistance()
      ->
        latitude as Float
        longitude as Float
        altitude as Float
        heading as Float
      <- result as Float: latitude + longitude + altitude + heading

    <?-
      Calculates a heading adjustment from the same navigation coordinates.
      Same 4 parameters as computeDistance, but only 2 functions share them.
      Below the threshold of 3 callables.
    -?>
    calculateHeading()
      ->
        latitude as Float
        longitude as Float
        altitude as Float
        heading as Float
      <- result as Float: heading + latitude + longitude + altitude

  defines program

    DataClumpDemo()
      stdout <- Stdout()
      distance <- computeDistance(latitude: 51.5, longitude: 0.12, altitude: 100.0, heading: 270.0)
      bearing <- calculateHeading(latitude: 51.5, longitude: 0.12, altitude: 100.0, heading: 270.0)
      stdout.println(`Distance: ${distance}`)
      stdout.println(`Bearing: ${bearing}`)

Common mistakes

E11053 — Adding a third function with the same 4 Float parameters (latitude, longitude, altitude, heading) triggers E11053. Extract a Coordinate record instead. See ek9 -h E11053 for details.

Incorrect:

    calculateHeading()
      ->
        latitude as Float
        longitude as Float
        altitude as Float
        heading as Float
      <- result as Float: heading + latitude + longitude + altitude

    estimateArrival()
      ->
        latitude as Float
        longitude as Float
        altitude as Float
        heading as Float
      <- estimate as Float: latitude + longitude + altitude + heading

Correct:

    calculateHeading()
      ->
        latitude as Float
        longitude as Float
        altitude as Float
        heading as Float
      <- result as Float: heading + latitude + longitude + altitude

Coming from another language?

Java: data clumps detected only by SonarQube or PMD (optional). Python: no detection. C++: no detection. Go: convention recommends structs but not enforced. EK9: compile-time detection when 3+ callables share 4+ matching parameters.

Keywords: smell, quality, limit, clump, boundary, parameter, function, refactoring, clean-code, threshold, E11053, data, extract, Fowler, record