Long Parameter List

• Too many parameters
• Too many arguments

• API Design
• Implementation

A method has a lot of parameters.

• Methods with 0 and 1 arguments are fine
• 2 parameters still good
• 3 parameters can be considered OK
• 4 and more parameters are usually too much

• MIMC Obviously MIMC is violated by long parameter lists.
• PSU: Long methods are hard to read it is often necessary to look up what all the parameters mean.
• ML: Parameters can be easily misinterpreted or can be given in the wrong order.
• EUHM: Methods with long parameter lists are neither easy to use nor hard to misuse, they are just easy to write.
• OOS: Following OOS leads to short parameter lists.
• HC: A long parameter list may be a sign of low cohesion.

• KISS: Introducing a method with many parameters is easy, adding a parameter is easy, neglecting refactoring is easy. Applying KISS here can be regarded sloppy or pragmatic, depending on the concrete situation.
• GP: Methods with many parameters are usually more potent than those with fewer parameters. But using GP to justify a long parameter list might also be a sign that the method should not have all these capabilities, i.e. it is lacking cohesion.

• Replace Parameter With Method
• Introduce Parameter Object
• Preserve Whole Object

The Windows API function CreateProcess takes ten arguments most of which are even optional. The function is cumbersome to use and hard to read because of the large number of parameters. Developers tend to avoid the use of the function and use simpler ones like ShellExecute (which still has six parameters) instead, or write wrapper functions for it. Some might be even tempted to use WinExec which is very easy to use but deprecated. In contrast to that the .NET method Process.Start can often be called with just one parameter.

Incomplete

• Martin Fowler: Refactoring: Improving the Design of Existing Software

Discuss this wiki article and the anti-pattern on the corresponding talk page.