例程可以有参数,这不是新闻。您可以根据需要定义任意多的参数,但是过多的参数会使您的例程难以理解和维护。
当然,您可以使用结构化变量作为解决方法:将所有这些变量放在单个结构中并将其传递给例程。事实上,使用结构来简化参数列表是Steve McConnell在Code Complete中描述的技术之一。但正如他所说:
谨慎的程序员避免将数据捆绑在一起,除非逻辑上是必要的。
因此,如果你的例程有太多的参数,或者你使用一个结构体来掩盖一个大的参数列表,你可能做错了什么。也就是说,你没有保持耦合松散。
我的问题是,什么时候我可以认为一个参数列表太大?我认为5个以上的参数太多了。你怎么看?
只有在某些参数是冗余的情况下,函数才可能有过多的参数。如果使用了所有参数,则函数必须具有正确的参数数量。以这个常用的函数为例:
HWND CreateWindowEx
(
DWORD dwExStyle,
LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
);
这是12个参数(如果将x,y,w和h捆绑为一个矩形,则为9个),还有从类名派生的参数。你将如何减少这种情况?你想把数字减少到更精确的程度吗?
不要让参数的数量困扰你,只要确保它是合乎逻辑的,并有良好的文档记录,让智能感知*帮助你。
*其他编码助手可用!
非常感谢你的所有回答:
It was a bit surprising to find people who also think (like I do) that 5 parameters is a good limit for the sanity of the code.
Generally, people tend to agree that a limit between 3 and 4 is good rule of thumb. This is reasonable as people usually have a bad time counting more than 4 things.
As Milan points, on average people can keep more or less 7 things in their head at a time. But I think that you can't forget that, when you are designing/maintaining/studying a routine, you have to keep in mind more things than just the parameters.
Some people consider that a routine should have as many arguments as it needs to. I agree, but only for a few specific cases (calls to OS APIs, routines where optimization is important, etc). I suggest to hide the complexity of these routines by adding a layer of abstraction just above these calls whenever possible.
Nick has some interesting thoughts on this. If you don't want to read his comments, I summarize for you: in a nutshell, it depends:
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.
The moral here is don't be afraid of showing your code to your peers, discuss with them and try to "identify areas where you have low cohesion and tight coupling".
Finally, I think wnoise much agrees with Nick, and concludes his satirical contribution with this poetical vision (see comments below) of the art of programming:
Programming is not engineering. Organization of code is an art because it depends on human factors, which depend too much on context for any hard rule.