Iris Classon
Iris Classon - In Love with Code

‘Stupid’ Question 18:In RE to best practices- what is the max amount of parameters a function should have (OO lang)?

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

A very popular code smell is: ‘Long parameter list’. I want to talk about that. What is the upper limit? What is ‘too long’ ? Yes- I know, this is another ‘it depends’. But I wanted to know what the majority thinks, so I started asking. And please keep in mind that I mean OO languages ;)

In RE to best practices- what is the max amount of parameters a function should have (OO lang.)?

Robert C. Martin talks about the number of parameters in his book Clean Coder:

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.

Steve McConnell in Code Complete states:

Limit the number of a routine’s parameters to about seven

When I ask around the majority of the devs answer from most popular answer to least:

  1. 3-4

  2. As few as you must have (…but’ often a general recommendation would follow, setting an upper limit)

  3. 5

  4. A few said 10

  5. Nobody said ‘go for it, as many as you like’

And why this recommendation?

  • Argument a) it indicates that your function *might* try to do to many things

  • Argument b) readability, hard to follow the flow, function *might* get to big

  • Argument c) According to Steve McConnell research shows that people have a hard time handling more than 7 chunks of information at the time.

  • Argument d) many parameters indicate that the data might be related and therefore should be grouped into a class

  • Argument e) long list of parameters indicate complexity- function should be broken up

My conclusion? I’ll strive towards small readable functions with preferrable less than 3-4 parameters, but I’ll have to see. It does depend. Or? What do you think?


Leave a comment below, or by email.
8/9/2012 12:36:02 AM
The lowest amount possible for most of the time. All the other SOLID principles will kind of make you go that way anyway. 

It's more of a 80%-20% rule where in 80% of the time you use 0 or one and 20% of time you use more. Usage may vary and percentages are just number to taking with a grain of salt. 

I think it is Martin that say if you need more than three than perhaps you need another class. 
8/9/2012 1:01:51 AM
As many as the number I had to put in this "human test" thing above. 
8/9/2012 1:41:22 AM
While in general i would go with 3-4, If things tend to get messy, i prefer using an object than individual parameters. This makes the code a bit more easily maintainable and extensiable as your interface need not change with change in # parameters. You can just add those additional parameters to the class as its additional properties. 
8/9/2012 3:07:40 AM
I think the maximum number of parameters should not be greater than three, because more parameters indicate that the method does more than it should do.

At the moment i am responsible for maintenance of an application which a colleague of mine called a "big ball of mud". And in this application many methods have a lot of parameters (5+). Those methods are doing more than the method name verbalise. Everytime i refactor those methods, the number of parameters are less or equal to three. 

Maybe there are situations where a large number of parameters makes sense, but i haven't found them so far :-) 
David Corbett
8/9/2012 7:03:55 AM
Maybe, the lesser the number of parameters, the longer (and more descriptive) the function name? 
8/9/2012 7:38:41 AM
Best practices are a nice guide, but I often feel people get super carried away think some rules are universal.

In this case I think you're right - more than 3 and it does suggest it might be a big stinky function that is going to make you cry.

But... if 6 parameters gives me the simplest possible code - save creating new classes and abstractions, or other awkward alternatives, then I'll happily pump in 6 parameters and let the best practice folk lose sleep whilst I get a good night's worth.

Enjoy your day :) 
James Curran
8/9/2012 8:49:06 AM
I'd go with McConnell's fairly high number of 7.  

There's just too many completely reasonable justifications for using many parameters.

Consider a simple Move() method on a graphical object.  You'd need a From X & Y and a To X & Y, and we're already past the 3 Martin wants to limit us to.

At 7, even if you are not doing too much in the method, the call is just going to be too hard to read, and it's time to consider refactoring it. 
Sam L
8/9/2012 1:29:55 PM
"Consider a simple Move() method on a graphical object. You’d need a From X & Y and a To X & Y, and we’re already past the 3 Martin wants to limit us to."

The from coordinates can be a Point object, same as the To coordinates, so that would be 2 parameters, not 4.

I think you should strive for 3 parameters or less. If you want to introduce more than three parameters, you should stop and think if you can avoid it.

But I agree with Nick's pragmatic approach. Don't make it a hard rule, there are some (rare) legimate cases for functions with many parameters. 
Esko Luontola
8/9/2012 2:54:51 PM
"Consider a simple Move() method on a graphical object. You’d need a From X & Y and a To X & Y, and we’re already past the 3 Martin wants to limit us to."

When X and Y always go together, it's a code smell if they are separate parameters. They should be wrapped into a Coordinate or Point class. Thus the Move() method needs only two parameters and the design will communicate better its intent. 
10/17/2012 10:49:34 AM
Since X & Y coordinates are given together as a "unit" and thus can be treated similar to a value type, a struct would be a better choice than a class. A class is overkill for this and will be less efficient than a struct. 

Last modified on 2012-08-08

comments powered by Disqus