如何将变量传递给函数？使用数组或变量？
当我尝试重构我的函数以满足新的需求时，我时不时地会遇到一个关键问题：
我应该添加另一个具有默认值的变量吗？或者我应该只使用一个数组，这样我就可以在不破坏 API 的情况下添加额外的变量？
When I try to refactor my functions, for new needs, I stumble from time to time about the crucial question:
Shall I add another variable with a default value? Or shall I use only one array, where I´m able to add an additional variable without breaking the API?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
除非您需要支持灵活数量的变量，否则我认为最好明确标识每个参数。在大多数情况下，您可以添加具有不同签名的重载方法来支持额外的参数，同时仍然支持原始方法签名。如果您使用数组来传递变量，这只会让 API 用户感到非常困惑。显然，有一些输入适合数组（多边形中的点列表、您希望执行操作的帐户 ID 列表等），但如果它不是一个变量，您可以合理地期望它是一个变量数组或列表，您应该将其作为单独的参数传递到方法中。
Unless you need to support a flexible number of variables, I think it's best to explicitly identify each parameter. In most cases you can add an overloaded method that has a different signature to support the extra parameter while still supporting the original method signature. If you use an array for passing variables it just makes it too confusing for users of your API. Obviously there are some inputs that lend themselves to an array (a list of points in a polygon, a list of account IDs you wish to perform an action on, etc.) but if it's not a variable that you would reasonably expect to be an array or list, you should pass it into the method as a separate parameter.
就像编程中的许多问题一样，正确的答案是“视情况而定”。
以 Javascript/jQuery 为例，一个好的经验法则是每次调用函数时是否需要该参数，或者该参数是否是可选的。例如，主 jQuery 函数本身需要一个表达式来确定操作将影响哪些元素：
尝试将此参数作为数组的一部分传递是没有意义的，因为每个 调用此函数的时间。
另一方面，许多 jQuery 插件需要几个可能是可选的杂项参数。按照惯例，这些通过“选项”数组作为参数传递。正如您所说，这提供了一个很好的界面，因为可以添加新参数而不影响现有 API。这也使得 API 变得干净，因为用户可以忽略那些不适用的选项。
一般来说，当涉及多个参数时，将它们作为数组传递是一个很好的约定，因为其中许多参数肯定是可选的。这将有助于清理许多 WIN32 API，尽管在 C/C++ 中处理数组比在 Javascript 中更困难。
Just like many questions in programming, the right answer is "it depends".
To take Javascript/jQuery as an example, one good rule of thumb is whether the parameter will be required each time the function is called or whether it is optional. For example, the main jQuery function itself requires an expression to determine what element(s) the operation will affect:
It makes no sense to try to pass this parameter as part of an array as it will be required every time this function is called.
On the other hand, many jQuery plugins require several miscellaneous parameters that may be optional. By convention, these are passed as parameters via an 'options' array. As you said, this provides a nice interface as new parameters can be added without affecting the existing API. This makes the API clean as well since the user can ignore those options that are not applicable.
In general, when several parameters are involved, passing them as an array is a nice convention as many of them are certainly going to be optional. This would have helped clean up many WIN32 API's, although it is more difficult to deal with arrays in C/C++ than in Javascript.
这取决于所使用的编程语言。
如果您使用普通的 OO 语言，如果您确实关心 API 一致性，则应该使用可以轻松扩展的对象。
如果这并不重要，可以选择更改方法签名并使用更多/不同的参数重载该方法。
如果您的语言不支持其中任何一个，并且您希望 API 是二进制稳定的，请使用数组。
It depends on the programming language used.
If you have a run-of-the-mill OO language, you should use an object that you can easily extend, if you are really concerned about API consistency.
If that doesn't matter that much, there is the option of changing the method signature and overloading the method with more / different parameters.
If your language doesn't support either and you want the API to be binary stable, use an array.
有几个必须考虑的因素。
There are several considerations that must be made.
Steve McConnell 在他的《Code Complete》一书中规定，一个函数的参数永远不能超过 7 个，而且很少有那么多。他提出了令人信服的论点——唉，我无法凭记忆引用这些论点。
最近，干净代码提倡更少的争论。
因此，除非要传递的东西数量非常少，否则它们应该以封闭结构传递。如果它们是同质的，则为数组。如果没有，那么应该为此目的构建一个相当轻量级的对象。
In his book Code Complete, Steve McConnell decrees that a function should never have more than 7 arguments, and rarely even that many. He presents compelling arguments - that I can't cite from memory, alas.
Clean Code, more recently, advocates even fewer arguments.
So unless the number of things to pass is really small, they should be passed in an enveloping structure. If they're homogenous, an array. If not, then a reasonably lightweight object should be built for the purpose.
你两者都不应该做。只需添加参数并更改所有调用者即可提供正确的默认值。原因是带有默认值的参数只能放在最后，并且无法在参数列表中的任何位置添加更多必需的参数，而不会存在误解的风险。
以下是应对灾难的关键步骤：
1.添加一两个默认参数
2. 有些调用者会提供它，有些则依赖默认值。
【半年过去了】
3.添加必需的参数（在它们之前）
4.更改所有调用者接受所需参数
5.接到电话或其他事件会让您忘记更改第#2部分中的实例之一
6. 现在你的程序可以完美编译，但是无效。
不幸的是，在函数调用语义中，我们通常没有机会通过名称来说明哪个值在哪里。
数组也不是一个合适的解决方案。数组应该用作类似对象的连接，在其上执行统一的活动。正如他们所说的这里，如果值得重构，那么现在就值得重构。
You should do neither. Just add the parameter and change all callers to supply the proper default value. The reason is that parameters with default values can only be at the end, and will not be able to add any more required parameters anywhere in the parameters list, without having a risk of misinterpretation.
These are the critical steps to disaster:
1. add one or two parameters with defaults
2. some callers will supply it, and some will rely on defaults.
[half a year passed]
3. add a required parameter (before them)
4. change all callers to accept the required parameter
5. get a phone call, or other event which will make you forget to change one of the instances in part#2
6. now your program compiles perfectly, but is invalid.
Unfortunately, in function call semantics we usually don't have a chance to say, by name, which value goes where.
Array is also not a proper solution. Array should be used as a connection of similar objects, upon which there's a uniform activity performed. As they say here, if it's worth refactoring, it's worth refactoring now.