📝 Enforce a maximum number of function parameters to encourage object parameter patterns.
💼 This rule is enabled in the following configs: 🌐 all, 🧮 complexity, ✅ recommended.
Enforce a maximum number of function parameters to encourage object parameter patterns.
LLMs frequently generate functions with many positional parameters. This makes function calls error-prone — parameter order is easy to confuse, and adding new parameters requires updating every call site.
This rule limits function parameters (default: 2) and encourages using a single options object with destructuring instead.
Constructors have a separate, higher limit (default: 5) to accommodate dependency injection patterns.
// Too many positional parameters
function fetchAttachment(
url: string,
logger: Logger,
maxSizeBytes: number,
timeoutMs: number,
allowedDomains: string[],
regulationId: string,
) {
// ...
}// Object parameter with destructuring
type FetchOptions = {
url: string;
logger: Logger;
maxSizeBytes: number;
timeoutMs: number;
allowedDomains: string[];
regulationId: string;
};
function fetchAttachment(options: FetchOptions) {
const { url, logger, maxSizeBytes, timeoutMs, allowedDomains, regulationId } =
options;
// ...
}Maximum allowed parameters for functions. Default: 2.
Maximum allowed parameters for class constructors. Default: 5.
Maximum allowed parameters for non-exported functions. Default: same as max.
This creates a useful tiering: exported functions (public API) are held to the stricter max limit and encouraged to use options objects, while internal helpers like handleError(error, message, context) get a relaxed limit.
{
"llm-core/max-params": [
"error",
{
"max": 2,
"maxConstructor": 5,
"maxInternal": 3
}
]
}Error messages follow a structured teaching format designed for LLM self-correction:
- What's wrong — identifies the function and parameter count
- Why — explains that positional parameters are error-prone
- How to fix — shows the exact transformation to an options object with the function's actual parameter names