How many parameters are too many?

Routines can have parameters, that's no news. You can define as many parameters as you may need, but too many of them will make your routine difficult to understand and maintain.

Of course, you could use a structured variable as a workaround: putting all those variables in a single struct and passing it to the routine. In fact, using structures to simplify parameter lists is one of the techniques described by Steve McConnell in Code Complete. But as he says:

>Careful programmers avoid bundling data any more than is logically necessary.

So if your routine has too many parameters or you use a struct to disguise a big parameter list, you're probably doing something wrong. That is, you're not keeping coupling loose.

My question is, when can I consider a parameter list too big? I think that more than 5 parameters, are too many. What do you think?

When is something considered so obscene as to be something that can be regulated despite the 1st Amendment guarantee to free speech? According to Justice Potter Stewart, "I know it when I see it." The same holds here.

I hate making hard and fast rules like this because the answer changes not only depending on the size and scope of your project, but I think it changes even down to the module level. Depending on what your method is doing, or what the class is supposed to represent, it's quite possible that 2 arguments is too many and is a symptom of too much coupling.

I would suggest that by asking the question in the first place, and qualifying your question as much as you did, that you really know all of this. The best solution here is not to rely on a hard and fast number, but instead look towards design reviews and code reviews among your peers to identify areas where you have low cohesion and tight coupling.

Never be afraid to show your colleagues your work. If you are afraid to, that's probably the bigger sign that something is wrong with your code, and that you already know it.

A function can only have too many parameters if some of the parameters are redundant. If all the parameters are used, the function must have the correct number of parameters. Take this often used function:

HWND CreateWindowEx
(
  DWORD dwExStyle,
  LPCTSTR lpClassName,
  LPCTSTR lpWindowName,
  DWORD dwStyle,
  int x,
  int y,
  int nWidth,
  int nHeight,
  HWND hWndParent,
  HMENU hMenu,
  HINSTANCE hInstance,
  LPVOID lpParam
);

That's 12 parameters (9 if you bundle the x,y,w and h as a rectangle) and there's also the parameters derived from the class name as well. How would you reduce this? Would you want to reduce the number more to the point?

Don't let the number of parameters bother you, just make sure it's logical and well documented and let intellisense^* help you.

^* Other coding assistants are available!

In Clean Code, Robert C. Martin devoted four pages to the subject. Here's the gist:

> The ideal number of arguments for a > function is zero (niladic). Next comes > one (monadic), followed closely by two > (dyadic). Three arguments (triadic) > should be avoided where possible. More > than three (polyadic) requires very > special justification -- and then > shouldn't be used anyway.

Some code I've worked with in the past used global variables just to avoid passing too many parameters around.

Please don't do that!

(Usually.)

If you start having to mentally count off the parameters in the signature and match them to the call, then it is time to refactor!

Thank you very much for all your answers:

• It was a bit surprising to find people who also think (like I do) that 5 parameters is a good limit for the sanity of the code.

• Generally, people tend to agree that a limit between 3 and 4 is good rule of thumb. This is reasonable as people usually have a bad time counting more than 4 things.

• As Milan points, on average people can keep more or less 7 things in their head at a time. But I think that you can't forget that, when you are designing/maintaining/studying a routine, you have to keep in mind more things than just the parameters.

• Some people consider that a routine should have as many arguments as it needs to. I agree, but only for a few specific cases (calls to OS APIs, routines where optimization is important, etc). I suggest to hide the complexity of these routines by adding a layer of abstraction just above these calls whenever possible.

• Nick has some interesting thoughts on this. If you don't want to read his comments, I summarize for you: in a nutshell, it depends:

>I hate making hard and fast rules like this because the answer changes not only depending on the size and scope of your project, but I think it changes even down to the module level. Depending on what your method is doing, or what the class is supposed to represent, it's quite possible that 2 arguments is too many and is a symptom of too much coupling.

The moral here is don't be afraid of showing your code to your peers, discuss with them and try to "identify areas where you have low cohesion and tight coupling".

• Finally, I think wnoise much agrees with Nick, and concludes his satirical contribution with this poetical vision (see comments below) of the art of programming:

>Programming is not engineering. Organization of code is an art because it depends on human factors, which depend too much on context for any hard rule.

This answer assumes an OO language. If you're not using one--skip this answer (this is not quite a language-agnostic answer in other words.

If you are passing more than 3 or so parameters (especially intrinsic types/objects), it's not that it's "Too many" but that you may be missing a chance to create a new object.

Look for groups of parameters that get passed into more than one method--even a group passed into two methods almost guarantees that you should have a new object there.

Then you refactor functionality into your new object and you wouldn't believe how much it helps both your code and your understanding of OO programming.

It seems like there are other considerations than mere number, here are some that come to mind:

1. logical relation to the primary purpose of the function vs. one-off settings

2. If they are just environment flags, bundling can be very handy

One of Alan Perlis's well-known programming epigrams (recounted in ACM SIGPLAN Notices 17(9), September, 1982) states that "If you have a procedure with 10 parameters, you probably missed some."

According to Steve McConnell in Code Complete, you should

> Limit the number of a routine's > parameters to about seven

For me , when the list crosses one line on my IDE, then it's one parameter too many. I want to see all the parameters in one line without breaking eye contact. But that's just my personal preference.

I generally agree with 5, however, if there is a situation where I need more and it's the clearest way to solve the problem, then I would use more.

Seven things in short term memory?

1. Name of the function
2. Return value of the function
3. Purpose of the function
4. Parameter 1
5. Parameter 2
6. Parameter 3
7. Parameter 4

In [Worst 5 Code Snippets][1], check the second one, "Is this a constructor". It has like over 37 ⋅ 4 ≈ 150 parameters:

> Here a programmer wrote this constructor [... S]ome of you may think yes its a big constructor but he used eclipse automatic code generation tools[.] NOO, in this constructor there was a tiny bug that I discovered, which made me conclude that this constructor was written by hand. (by the way this is only the top part of the constructor, its not complete). > > ![constructor with over 150 parameters][2]

[1]: https://kababji.wordpress.com/2009/09/07/worst-5-code-snippets-till-now/ "Worst 5 Code Snippets" [2]: http://i.stack.imgur.com/Hltui.jpg

One more than necessary. I don't mean to be glib, but there are some functions that necessarily need quite a few options. For example:

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

There are 6 arguments, and every one of them is essential. Furthermore, there's no common link between them to justify bundling them. Maybe you could define "struct mmapargs", but that would worse.

According to Perl Best Practices, 3 is okay, 4 is too many. It's just a guideline, but in our shop that's what we try to stick to.

I'd draw the limit for public functions at 5 parameters myself.

IMHO, long parameter lists are only acceptable in private/local helper functions that are only meant to be called from a few specific places in the code. In those cases, you may need to pass a lot of state information along, but readability isn't as big of a concern since only you (or someone who will maintain your code and should understand the fundamentals of your module) have to care about calling that function.

A related question you should be considering is how cohesive the routine is. A large number of parameters may be a smell that's telling you that the routine itself is trying to do too much and hence it's cohesion is suspect. I agree that a hard and fast number of parameters is probably impossible but I would guess that a high cohesion routine would imply a low number of parameters.

97 sounds just about right.

Any less and you lose flexibility.

I stop at three parameters as a general rule of thumb. Any more and it's time to pass an array of parameters or a configuration object instead, which also allows for future parameters to be added without changing the API.

A length restriction on a parameter list is just one more restriction. And restriction means applied violence. It sounds funny, but you can be non-violent even when programming. Just let the code dictate the rules. It is obvious that if you have many parameters, the body of the function/class method will be big enough to make use of them. And big code snippets usually can be refactored and split into smaller chunks. So you get solution against having many parameters as free bonus, since they are split among the smaller refactored pieces of code.

One thing I would point out from a performance perspective is that depending on how you pass parameters to a method, passing lots of parameters by value will slow the program down because each parameter has to be copied and then placed on the stack.

Using a single class to encompass all of the parameters would work better because a single parameter passed by reference would be elegant and cleaner, and quicker!

According to me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be

1. Your Method is doing too much and you need to refactor.
2. You might want to consider using a collection or some data structure.
3. Rethink your class design, maybe some things do not need to be passed around.

From an angle of ease of use or ease of reading code, I think when you need to kinda "word wrap" your method signature, that should make you stop and think,Unless you feel helpless and all efforts of making the signature smaller lead to no result. Some very good libraries in past and present use more than 4-5 prams.

My rule of thumb is that I need to be able to remember the parameters long enough to look at a call and tell what it does. So if I can't look at the method and then flip over to a call of a method and remember which parameter does what then there are too many.

For me that equates to about 5, but I'm not that bright. Your mileage may vary.

You can create an object with properties to hold the parameters and pass that in if you exceed whatever limit you set. See Martin Fowler's Refactoring book and the chapter on making method calls simpler.

It heavily depends on the environment you're working in. Take for example javascript. In javascript the best way to pass in parameters is using objects with key/value pairs, which in practice means you only have one parameter. In other systems the sweet spot will be at three or four.

In the end, it all boils down to personal taste.

I'll agree with 3 is okay, 4 is too many as a guideline. With more then 3 parameters, you are inevitably doing more then one task. More then one tasks should be split into separate methods.

However, if I looked at the latest project I've worked on, the exceptions would abound and most cases would be hard to get down to 3 parameters.

If I have 7-10 parameters in one routine I look at bundling them into a new class but not if that class would be nothing but a bunch of fields with getters and setters - the new class has to do something other than shuffle values in and out. Otherwise I'd rather put up with the long parameter list.

It's a known fact that, on average, people can keep 7 +/- 2 things in their head at a time. I like to use that principle with parameters. Assuming that programmers are all above-average intelligent people, I'd say everything 10+ is too many.

BTW, if parameters are similar in any way, I'd put them in a vector or list rather than a struct or class.

I would base my answer on how often the function is called.

If it is an init function that is only ever called once then let it take 10 parms or more, who cares.

If it is called a bunch of times per frame then I tend to make a structure and just pass a pointer to it since that tends to be faster ( assuming that you are not rebuilding the struct every time as well ).

According to Jeff Bezos of Amazon fame, no more than can be fed with two pizzas:

I agree with Robert Martin's quote in Clean Code (as cited above): the fewer parameters the better. More than 5-7 parameters and method calls become pretty hard to comprehend. Things get especially bad if some of the parameters are optional (and so take null values), or if all the parameters have the same type (making it even harder to figure out which parameter is which). If you can bundle parameters into cohesive domain objects like Customer and Account, your code will be much more pleasant to work with.

There is an edge case: if you have a method call that takes a variable number of parameters which form a logical set, there's less cognitive overhead having more parameters. For example you may need a method that specifies a number of HTTP request retries, in terms of the number of milliseconds between retries. Three retries at 1s, 2s, and 3s intervals could be specified as:

retries(1000, 2000, 3000)

In this limited case, adding more parameters to a call doesn't increase the mental overload that much.

Another consideration is if your language supports named parameter lists and allows you to leave out optional parameters. Larger named parameter lists are easier to comprehend than larger unnamed parameter lists.

But I'd still err on the side of fewer rather than more parameters.

I'd say as long as you have overloads that have 2-4 than you're good to go up higher if you need it.

I think the actual number really depends on what makes logical sense with the context of the function. I agree that around 4-5 parameters starts getting crowded.

In the case of setting flags, a great way to handle this situation is to enumerate the values and OR them together.

IMO, the justification for a long param list is that the data or context is dynamic in nature, think of printf(); a good example of using varargs. A better way to handle such cases is by passing a stream or xml structure, this again minimises the number of parameters.

A machine surely wouldn't mind a large number of arguments, but developers do, also think of the maintenance overhead, the number of unit test cases and validation checks. Designers also hate lengthy args list, more arguments mean more changes to interface definitions, whenever a change is to be done. The questions about the coupling/cohesion spring from above aspects.