函数中参数顺序的约定 [英] Conventions for order of parameters in a function

问题描述

在编写函数时，我的大脑总是花费几毫秒来检查给定函数的哪个参数顺序最适合。

我应该写：

  public AddComment（long userID，string title，string text）
  

或者：

  public AddComment（string title，string text，long用户名）
  

为什么不能：

  public注释AddComment（字符串标题，长用户ID，字符串文本）
  

订购功能参数时是否遵守任何规则？
您将首先放置哪个参数？哪些参数会跟随？

解决方案

我通常只应用3个规则： / b>

• 如果语言允许将散列/映射/关联数组作为单个参数传递，请尝试选择传递它。这对于具有> = 3参数的方法尤其有用，ESPECIALLY将这些相同参数传递给嵌套函数调用。

  
  
  

  这样可以更容易地进行维护 - 添加另一个参数（尤其是在10层深度嵌套函数调用之间传递相同参数列表时）涉及在代码中更改1位（最终调用者），而不是使用该列表并将其传递到其他位置的每个单一函数。

  
  
  

  这在C ++等语言中没有类型检查的小缺点（例如，您的编译器无法检查散列/映射是否包含对于预期类型的​​键的正确类型的值） - 如果这是一个问题，您可以将该参数映射封装为结构/类。

如果一种语言允许参数的默认值（例如C ++， Sybase存储过程），您显然将可选参数保留为最后一个参数，并且使用值指定参数的可能性较小，在列表中的后面它应该去。 否则，在任何逻辑分组中最可读/可维护的顺序排列它们。



这可能有点主观 - 例如next / previous weight / height可以订购 next_weight，next_height，prev_weight，prev_height 或 next_weight，prev_weight，next_height，prev_height 同样有效。再次，三个主要考虑因素是您的可读性/逻辑性以及易于维护。





就可读性而言，您可以按照类型或意义对它们进行排序。



至于逻辑性，你可以按照它们的意义排序它们（例如，将所有下一个组合在一起，或者将所有高度组合在一起），或者通过其他地方施加的某个顺序 - 例如对应数据库表中的列顺序或GUI中的字段顺序，因为它很可能会改变）。



就维护而言，如果没有明显有意义的顺序结晶，字母数字顺序是最好的，因为它允许非常简单的方法来查找参数通过扫描，特别是决定插入新参数的位置。

In writing functions my brain always spends a few milliseconds to check which order of parameters would be best for a given function.

should I write:

    public Comment AddComment(long userID, string title, string text)

Or probably:

    public Comment AddComment(string title, string text, long userID)

Why not:

    public Comment AddComment(string title, long userID, string text)

Do you follow any rules when ordering the parameters for your functions? Which parameter would you place first and which would follow?

解决方案

There are only 3 rules I usually apply:

• If a language allows passing a hash/map/associative array as a single parameter, try to opt for passing that. This is especially useful for methods with >=3 parameters, ESPECIALLY when those same parameters will be passed to nested function calls.

  This allows for easier maintenance - adding another parameter (especially when that same list of parameters is passed between 10-level-deep nested function calls) involves changing 1 place in the code (the ultimate caller) instead of EVERY single function which takes that list and passes it on elsewhere.

  This has a minor drawback of no type checking in languages like C++ (e.g. your compiler can't check whether the hash/map contains correct types of values in it for expected types of keys) - if that's a concern, you can encapsulate that parameter map as a struct/class instead.

• If a language allows default values for parameters (such as C++, Sybase stored procedures), you obviously leave the optional parameters to be the last, and the less likely the parameter is to be specified with a value, the later in the list it should go.

• Otherwise, order them in whatever logical grouping is most readable/maintainable.

  This may be a bit subjective - e.g. next/previous weight/height can be ordered next_weight,next_height, prev_weight, prev_height or next_weight, prev_weight, next_height, prev_height equally validly. Again, the 3 main considerations are readability/logicaleness for you, and ease of maintenance.

  As far as readability, you can order them by type, or by meaning.

  As far as "logicalness", you can order them by meaning (e.g. group all "next" together, or all heights together), OR by some order imposed elsewhere - for example, column order in a corresponding database table, or field order in a GUI (worse, as it's likely to change).

  As far as maintenance, if no obvious meaningful order crystallizes, alphanumeric order is the best since it allows VERY easy way to find a parameter by scanning and especially to decide where to insert a new parameter.

这篇关于函数中参数顺序的约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！