How many parameters should a method have?

Never work with absolute numbers. These metrics do not work. If something like this could be determined the compilers would forbid more.

You can establish something for your project, but it's silly. In the background this is what is called "good practice", that is, the person establishes a rule because he does not know how to solve the problem in a convenient way.

You should have as many parameters as you need.

It has too many parameters when they do not serve the purpose of the method. They are too much when you are passing what you do not need. In general if you are not using a parameter in a given situation there should be a version of it without the parameter. For all there is exception. We should be pragmatic.

Some people will say that the solution to many parameters is to pass an object. It even makes some sense, in fact you have several related parameters an object there reduces the amount of parameters. But does this actually have any benefit?

Will you create an object just to meet this "requirement" of few parameters? And if you do this, you've formally decreased the number of parameters, but the amount of information you entered is the same. What is the benefit of this? Performance? But is there no cost to build this object? Type less? But do you type less anyway? Can you handle this object correctly? Do you know that you can have the different semantics, since the parameters are probably passed by reference?

What if the object already exists? Great, right? Just pass it. I do not say there's something wrong with this, if it makes sense, it really does. If you know how to handle this situation well, no problem. But anyone who likes to say in general what is good to do will say that this causes excessive coupling since it is almost certain which will be passing data that is not required for the method.

Here's an addition to the Clean Code book or everything Uncle Bob says, as is there an answer (and reproduced in another answer here) in the question that inspired the book. The same thing happens with Code Complete . I think every programmer should read these books. But if he has no personality, he does not have a very good base, that book could wreck the person's mind. There are incoherent things in the book, there is a lot of ideology, there is a lot without plausible justification or without context. I'm afraid when an unwary reads these things and starts following blindly.

Most answers there in the question speak of low numbers and try to justify why. The problem is that they do not give another solution and the other solution suffers essentially from the same problem. There is no magic. If the problem is complex the solution will be complex. It just can not be complicated. And many times trying to make up the complexity programmers tend to make everything more complicated. They add layers over unnecessary layers. Just creating an object just to avoid passing arguments is an unnecessary layer that does not solve anything since you will have to deal with various information in the same way.

There you see that people have a lot of opinion and little real sense. The closest thing to a solution is to create an object to avoid passing several parameters, which does not solve anything and makes the code more complicated.

Of course many parameters usually show that the method is doing too many things or the data structure is poorly formulated. But this has to be analyzed on a case-by-case basis. Of course it gets to a point where things start to get messy.

I want to point out that no one has given a solution to the case that it makes sense for the method to have multiple parameters. Nobody says this because it depends a lot on context and in many cases can not do this to solve the problem in fact.

What can not really be passing arguments without necessity. If the method is doing too many things, it probably gets too many parameters. But the problem there is of responsibility and not of parameters in excess. Solve the problem right. This is the same problem as number of rows that the function should have .

People think things are orthogonal when they are not. They think that by changing the place argument it solves some problem, when it just changes it.

What is the maximum number of parameters a method should have?

  

The optimal number of arguments to a method is zero (niladic). In   followed by one (monadic) followed closely by two (dyadic). Three   (triadic) arguments should be avoided whenever possible. More of   three (polyadic) requires very special justification - and should not   be used anyway.

And as we always have this "very special justification", there is a certain number of parameters that you say are correct in a method, the question is the need you are having, what your method is going to what business rules are involved in this process. Here comes your good sense, you also may not want to leave parameters unusable. Create the method using as few parameters as possible.

I really like the following opinion on the subject:

  

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

Conclusion

It varies from project to project, you should get the correct number of parameters according to your need.