How many parameters should a method have?
What is the maximum number of parameters a method should have?
When should one consider that there are too many parameters?
And what to do in this case?
Tupiniquim and object-oriented version of the question: design-how many parameters are too many?
4 answers
Never work with absolute numbers. These metrics don't work. If something like this could be determined the compilers would prohibit a larger number.
You can establish something for your project, but it's nonsense. Basically this is what is called "good practice", that is, the person sets a rule because he does not know how to solve the problem conveniently.
It must have as many parameters as required .
Has too many parameters when they they do not serve the purpose of the method. They are too much when you are going through 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 everything there is an exception. We must be pragmatic.
Some people will say that the solution for many parameters is to pass an object. It even makes some sense, in fact if you have several related parameters an object there reduces the amount of parameters. But it brings some benefit indeed?
Will you create an object just to meet this" requirement " of few parameters? And if it does, it formally decreased the amount of parameters, but the amount of information that entered is the same. What is the benefit of this? Performance? But does it not cost to build this object? Type less? But type less really? Do you know how to handle this object correctly? Know that it may have different semantics, since most likely the parameters end up being passed by reference?
What if the object already exists? Great, right? Just pass it. I'm not saying there's something wrong with this, if it makes sense, come on. If you know how to handle this situation well, no problem. But those who like to say in general what is good to do will say that this causes excessive coupling (this is the most important thing to read) since it is almost certain that you will be passing data that is not necessary for the method.
Here fits an addendum about the Clean Code Book or all the that Uncle Bob speaks, since there is an answer (and reproduced in another answer here) in the question that served as the inspiration that quotes the book. the same is true with Code Complete . I think every programmer should read these books. But if he doesn't have personality, he doesn't have a very good foundation, that book can destroy a person's mind. There are incoherent things in the book, there is a lot of ideology, there is a lot of things without plausible justification or it is without context. I'm afraid when an unwary reads these things and begins to follow blindly.
Most of the answers there in the question speak of low number and try to justify why. The problem is that they do not give another solution or 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't be complicated. And often trying to make up the complexity programmers tend to make everything more complicated. Adding layers on top of layers no need. Just the fact of creating an object just to avoid passing arguments is an unnecessary layer and that does not solve something since it 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. What comes closest to a solution is creating an object to avoid passing multiple parameters, which doesn't solve something and makes the code more complicated.
Of course having many parameters usually shows that the method is doing too much 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 confusing.
I want to point out that no one gave a solution to the case that makes sense the method have multiple parameters. No one says this because it depends a lot on context and in many cases has no way to do this to solve the problem in fact.
What can't even pass arguments without need. If the method is doing too many things it probably gets too many parameters. But the problem there is responsibility and not excessive parameters. Solve the problem the right way. It is the same problem as the number of rows that the function should have .
People think things are orthogonal when they are not. They think that changing the place argument solves some problem, when it only changes the place.
What is the maximum number of parameters a method should have?
The optimal number of arguments for a method is zero (niladic). In next comes one (monadic), followed closely by two (dyadic). Three (triadic) arguments should be avoided whenever possible. More than three (polyadic) requires very special justification - and then it should not be used anyway.
and since we always have this "very special justification", there is no number certain parameters you say are correct in a method, the question is the need you are having, what your method will do, what business rules are involved in this process. Here comes your common sense, you may not also want to leave unused parameters. Create the method using as few parameters as possible.
I really like the opinion below on the topic:
I hate making hard and fast rules like this because the answer change not only depending on the size and scope of your project, but I think changes even 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
varies from project to project, you should fetch the correct number of parameters according to your need.
Metrics are relevant, you should use them!
You should instead make use of "classic" values and rely on them to, if they are "disobedient", do the proper investigation, which may result in the need for code adjustment or the finding of a false positive. In this sense, if you make use of Java, I understand that you should make use of tools such as Checkstyle and PMD, eventually calibrate the values to a reference value to be used in your context. For example, saved error, Checkstyle suggests a maximum of 7 arguments (default value of this tool).
If it exceeds 7, then it is appropriate to investigate. It doesn't mean there is an error, nor does it mean that methods with less than 7 are "correct", right? However, there is now a limit that can be automatically checked. Maybe your context sets to 5 or even to 25 (which is greater than the number of registers in an i7), anyway, and in both cases, you'll have guidance on where offer additional attention.
Is not a rule! Just as quoted by other friends, it should be take into account the need for work.
Without Parameter:
var product = new BllProduct
{
Code = TxtQueryByCode.Text,
Size = TxtQueryBySize.Text,
Reference = TxtQueryByReference.Text,
Description = TxtQueryByDescription.Text,
DataPagination = dataPagination
};
product.FetchData();
With parameter:
var product = new BllProduct()
product.FetchData(TxtQueryByCode.Text, TxtQueryBySize.Text,
TxtQueryByRefence.Text, TxtQueryByDescription.Text, OffSetValue,
PageSize);
FechData () is an interface method and it would be complicated to use this interface in other parts of the system. To do this I have to leave some parameters NULL, since in my case a client does not have searches by size. Or create a search method for each business, but prefer reuse the method because I think it is simpler.
This is just an example of the context of my work, there are moments that I use some parameters as well, for example:
public static void ShowReport(string path, string reportName,
bool isEmbeddedResource,
Dictionary<string, object> dataSources)
{
var frmReportView = new FrmReportView(path, reportName, isEmbeddedResource,
dataSources);
frmReportView.Show();
}
This method is generic and its main work does not change. I can use it to display any report without the need to modify its parameters for each new report. Notice, I passed up many parameters but the context of the activity was different for each case.