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?
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.
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.
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 me there could be cases where you will exceed 4 or some fixed number. Things to lookout could be
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.
According to Steve McConnell in Code Complete, you should
When is something considered so obscene as to be something that can be regulated despite the 1st Amendment guarantee to free speech? According to Justice Potter Stewart, "I know it when I see it." The same holds here.
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.
I would suggest that by asking the question in the first place, and qualifying your question as much as you did, that you really know all of this. The best solution here is not to rely on a hard and fast number, but instead look towards design reviews and code reviews among your peers to identify areas where you have low cohesion and tight coupling.
Never be afraid to show your colleagues your work. If you are afraid to, that's probably the bigger sign that something is wrong with your code, and that you already know it.