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?
This question is related to
parameters
language-agnostic
The answer is
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.
According to Jeff Bezos of Amazon fame, no more than can be fed with two pizzas:
It seems like there are other considerations than mere number, here are some that come to mind:
logical relation to the primary purpose of the function vs. one-off settings
If they are just environment flags, bundling can be very handy
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!
It seems like there are other considerations than mere number, here are some that come to mind:
logical relation to the primary purpose of the function vs. one-off settings
If they are just environment flags, bundling can be very handy
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.
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.)
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!
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!
According to me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be
- Your Method is doing too much and you need to refactor.
- You might want to consider using a collection or some data structure.
- 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.
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."
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!
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.)
According to Steve McConnell in Code Complete, you should
Limit the number of a routine's parameters to about seven
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.
It seems like there are other considerations than mere number, here are some that come to mind:
logical relation to the primary purpose of the function vs. one-off settings
If they are just environment flags, bundling can be very handy
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 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.
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.
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!
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.
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.
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'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.
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.
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 ).
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."
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 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.
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.
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.
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.
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.
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.
According to Jeff Bezos of Amazon fame, no more than can be fed with two pizzas:
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.
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.
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.
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.
According to Jeff Bezos of Amazon fame, no more than can be fed with two pizzas:
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.
It seems like there are other considerations than mere number, here are some that come to mind:
logical relation to the primary purpose of the function vs. one-off settings
If they are just environment flags, bundling can be very handy
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.
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.
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.
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."
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.
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!
According to me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be
- Your Method is doing too much and you need to refactor.
- You might want to consider using a collection or some data structure.
- 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.
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.
In Worst 5 Code Snippets, 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).
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.
Any less and you lose flexibility.
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.
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.
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.
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.
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!
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.
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.
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!
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.
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.
According to Jeff Bezos of Amazon fame, no more than can be fed with two pizzas:
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.
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.
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 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 ).
In Worst 5 Code Snippets, 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).
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!
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.
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.
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."
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 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 Steve McConnell in Code Complete, you should
Limit the number of a routine's parameters to about seven
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.
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.
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 ).
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.
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.
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.
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.
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 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.
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.
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.
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.
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.)
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 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.
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.
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.
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 Steve McConnell in Code Complete, you should
Limit the number of a routine's parameters to about seven
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.
According to Steve McConnell in Code Complete, you should
Limit the number of a routine's parameters to about seven
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.
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.
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.
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.
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.
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.
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.
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.
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.
Any less and you lose flexibility.
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.)
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.
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.
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.
Seven things in short term memory?
- Name of the function
- Return value of the function
- Purpose of the function
- Parameter 1
- Parameter 2
- Parameter 3
- Parameter 4
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.
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.
According to me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be
- Your Method is doing too much and you need to refactor.
- You might want to consider using a collection or some data structure.
- 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.
Seven things in short term memory?
- Name of the function
- Return value of the function
- Purpose of the function
- Parameter 1
- Parameter 2
- Parameter 3
- Parameter 4
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.
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.
According to me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be
- Your Method is doing too much and you need to refactor.
- You might want to consider using a collection or some data structure.
- 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.
Source: Stackoverflow.com