Long Parameter List
A Long Parameter List makes calls error-prone and unreadable and signals weak abstractions. Group related arguments into parameter objects or value objects, use builders for optional fields, and split methods that do too much.
A Long Parameter List is a function or constructor that takes so many arguments that calls become hard to write correctly and hard to read. createOrder(id, name, addr, city, zip, country, taxRate, currency, coupon, notes) is easy to mis-order and impossible to scan.
Why It Happens
Parameters accumulate the same way method bodies grow: each new requirement adds one more argument. Functions that do too much naturally need many inputs. Sometimes related data that should travel together as one object is passed as separate scalars instead, so a single concept spreads across several parameters.
Why It Hurts
Long lists are error-prone: adjacent parameters of the same type can be transposed with no compiler complaint, and callers must remember an arbitrary order. They are unreadable, especially in languages without named arguments, where a call is a row of unlabeled literals. They signal low cohesion — the function likely mixes concerns or lacks an abstraction. Optional parameters lead to chains of null/undefined placeholders. Adding or removing a parameter forces edits at every call site.
Warning Signs
- Functions or constructors with roughly six or more parameters.
- Several parameters of the same type in a row.
- Calls that pass many
null/Noneplaceholders for optional values. - Groups of parameters that always appear together across many functions.
Better Alternatives
Introduce a Parameter Object: bundle related arguments into a single, named type (Address, OrderRequest) that documents the grouping and can validate itself. Use the Builder Pattern when there are many optional fields, giving each a name and default. Promote conceptually-unified data into value objects. If the method needs many inputs because it does many things, splitting the method is often the real fix.
How to Refactor Out of It
Look for parameters that naturally cluster (the address fields, the pagination fields) and extract each cluster into a parameter object, migrating callers. For constructors with many optional fields, add a builder and deprecate the telescoping constructor. Where the long list reflects a method doing too much, decompose the method first; the parameter count often drops on its own. After refactoring, verify call sites read clearly and that the type system now prevents argument transposition within each grouped object.