How do I convince my coworker that methods with 26 parameters are bad practice?

Question

Title says it all... we've debated this without any progress.

Closest related questions I could find:

• How many parameters are too many?
• Worst Java practice found in your experience?
• What “bad practice” do you do, and why?

Answer 1

Ask him try to setup a unit testing harness for it where HE has to pass in all of the real/mock objects and account for every possible testing scenario.

Answer 2

There could be a few ways to do this.

1. Ask someone else to try to make heads or tails of it. A kind of hallway test for the code.
2. Wait three months and then see if this person can still use the method (at 26 parameters, they're probably going to require some time to figure out what does what and why).
3. Is there any way the parameters can be vectorized? Are they all of different types, or all ints? Because if they can be vectorized, would a vector (or a dictionary/hashmap) be such a bad compromise?

Answer 3

Ask him, what happens if one data passed as parameter becomes obsolete in the future and have to be deleted from the parameter-list. Who will change all calls to this method, especially if the parameter was in the middle of this list?

Answer 4

Ask him to describe the API in his own words. The parameter order, the meaning of all the parameters.

Look for past bugs that were caused by API users failing to grasp this monstrosity. Maybe some bugs were caused by invalid parameters (True instead of False as parameter 13, which is someImportantFlag).

Answer 5

It all comes down to API confusion ... imagine if you were the developer that had to call a method with 26 parameters. What if the method throws an exception, is there a problem with the 9th argument or the 23rd?

The API should be simpler than that

Answer 6

I'd suggest just trying to demonstrate that if they're creating methods with that many parameters, chances are they really should be breaking it down into much smaller methods, which results in code that is, overall, far more maintainable and readable. Sure, you'll end up with a lot of small methods, but modern IDEs have easy-to-navigate method trees for a reason.

Answer 7

You don't... you have him explain why it's NOT bad practice.

Listen to his points and tell him the reasons you would do it another way.

Answer 8

By showing your coworker a better way and explaining why it is better. I hope you don't think I'm being facetious, but with no further information from you I find it difficult to diagnose exactly why 26 parameters are bad for your situation. Rarely, I admit, but I have written functions and subroutines with many many arguments when that was the best design choice.

Regards

Mark Westwood

Answer 9

I would suggest to him that it is likely that there is a concept/domain entity/other abstraction that is being passed to this function, and that should be explicitly represented as an object. Passing the object is simpler, and allows things such as validation of the object, helper functions, etc. be attached to the class.

Besides, it is better (more maintainable/better organized/simpler) to explicitly represent these objects.

I bet if you look at the examples of 26-parameter functions, that you can come up with some concept/entity to represent what is really being passed.

Answer 10

Maybe try to read some literature on the subject together, at my company we read this book:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

and had a session where all the developers sat down and had a talk about how to work together.

It helped in bringing the different developer cultures together.

Answer 11

You might find this of interest:

• How many parameters are too many?

Answer 12

Are there any metrics you can run that show the amount of calls to the said method? (Just wondering whether it's a question of being too generic a method, that should probably be broken down.)

Hmm... I'd love to see the docblock for that one. :-)

Answer 13

Wait for a lot of people to reply to this post, and then give him a link to it. I guarantee he won't be able to argue with that; and if he does, it's not worth your time.

Answer 14

Well, 26 parameters or not, it's very debatable if it's a good idea or not. Anyways, I've seen someone deal with this problem by replacing the 26 parameters with a single structure that contained the 26 parameters. Actually, the Windows API has a few functions that have quite a few parameters, although 26 is quite a lot. (But several are between 10 and 16 parameters.)

So explain to him that 26 parameters are bad and he'll replace them with random structures with 26 fields each...

Answer 15

What is the size of the method body? I would guess that with that many parameters, the method body is big, complex, and thus, bug-prone. It is difficult to argue that big methods are easy to maintain.

How cohesive is a method with 26 parameters? Even if you could put all those parameters in one class, would you still access 26 different fields in a method? Hint: the method is probably doing too much.

Answer 16

Corporate Coding standards are very convincing usually. We use structures when it is necessary to pass such a lot parameters.

Answer 17

Show him Atwood's Code Smells. Nuff Said.

If that doesnt work. show your colleague A Taxonomy for "Bad Code Smells"

Answer 18

Methods with lots of parameters are not necessarily bad. It depends on what the parameters are, for instance. I maintain code with some methods that take dozens of parameters, because those parameters represent scalar values in an object, and the object's creation is the purpose of this method.

You could reorganize the parameters if you wanted; you could put them all in a map, but then there's no way to be sure that they're all present. You could create the object manually, but then you either have a constructor with 26 parameters or you have 26 setXXXX method calls. If your object requires all those parameters to be complete, I'd say you're stuck with the constructor approach or the factory method. Otherwise you are relying on the user setting up the object correctly every time.

What's better?

createTransation(date, username, transAmt, currency, accountNum, resultCode, ...);

Transaction trans = new Transaction(date, username, tranasAmt, currency, ...);
createTransaction(trans);

Transaction trans = new Transaction();
trans.setDate(date);
trans.setUsername(username);
// etc
createTransaction(trans);

Now, if your method has a handful of data parameters and a handful of control parameters, such as flags to chose some mode of operation, then it becomes problematic to use these methods, and you should explain to him that he should keep his code simpler and more focused. A method with lots of control parameters probably has a complex control path as well, and might be difficult to maintain. However, it's common for a single entry point to a complicated process to have lots of arguments; consider the command line for your compiler: you might have dozens of flags easily. But in this case it should be possible to group the options into a single structure; this makes it easier to determine which options must be specified, which have default behaviour, etc.

Transaction trans = new Transaction(date, username, tranasAmt, currency, ...);
Options opts = new Options(DEFERRED, VALIDATE, STORE);
createTransaction(trans, opts);

The original question is rather vague but it's important to remember that sometimes code complexity is warranted, or at least not wrong.

Answer 19

It Depends

It depends on what the parameters are, and what they mean.

While 26 parameters seems offhand to be excessive, it may be acceptable in some cases (DAL methods that map to stored procedures come to mind).

The semantics of the parameters are more important than their number - look at the parameter list and ask "if this was a database table's columns, would I need to take projections to normalize it?". Also ask "if this was a database table's columns, would they make sense as attributes of a single entity?"

In many cases, the presence of excess parameters indicates missing classes in the design.

Answer 20

Make him write the unit tests.