Data Clump
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). While phpmd and phpstan are listed as detection tools, automated detection is marked as 'no' — these tools can flag long parameter lists but cannot automatically determine whether parameters form a conceptual group that warrants extraction. Identifying true data clumps requires human judgment during code review to recognize that the same 3+ fields travel together across multiple signatures.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix shows a single signature change, but data clumps by definition appear in 'multiple function signatures' per the code_pattern. Extracting an Address or Location class requires creating the new class, updating all call sites passing those parameters, and modifying all receiving functions — a coordinated refactor across multiple files but typically within one domain area.
Closest to 'persistent productivity tax' (b5). Data clumps create ongoing friction: the detection_hints note they 'drift out of sync' across signatures, parameters must be threaded through multiple layers, and changes to the group require updates everywhere. The missing abstraction imposes a tax on many work streams (any feature touching those parameters), but doesn't define the system's architecture — it's a localized structural problem that compounds over time.
Closest to 'notable trap' (t5). The misconception explicitly states developers believe 'Passing multiple related parameters is just a style issue.' This is a documented gotcha that most developers eventually learn — they don't initially recognize that data clumps signal missing domain concepts and often reveal behaviour that should move to the extracted class. The trap is cognitive: the pattern looks harmless until you understand OOP abstraction principles.
Also Known As
TL;DR
Explanation
A data clump is a group of variables that always appear together — passed as a parameter list, stored as parallel arrays, or initialised together. If you see $firstName, $lastName, $email passed as three separate parameters in multiple functions, they form a data clump. The refactoring is to introduce a class (User, Contact) that holds them together. Data clumps and Long Parameter Lists are closely related — fixing one often fixes the other.
Common Misconception
Why It Matters
Common Mistakes
- Passing latitude, longitude, and zoom as separate parameters to every mapping function instead of a Location object.
- Using parallel arrays (names[], emails[]) instead of an array of objects.
- Defining the same group of parameters in multiple function signatures — they drift out of sync.
- Not adding behaviour to the extracted class — a plain data holder is better than a clump but a value object with validation is better still.
Code Examples
// Same group of primitives repeated across multiple functions
function createUser(string $street, string $city, string $postcode) {}
function updateAddr(int $id, string $street, string $city, string $postcode) {}
function validateAddr(string $street, string $city, string $postcode): bool {}// Extract into a value object
readonly class Address {
public function __construct(
public string $street,
public string $city,
public string $postcode,
) {}
}
function createUser(Address $address) {}
function updateAddr(int $id, Address $address) {}
function validateAddr(Address $address): bool {}