合并函数参数的适当命名约定是什么？

What is an appropriate naming convention for a merge function's parameters?

本文关键字：命名约定 是什么 函数 参数 合并      更新时间：2023-10-16

我正在编写一个C++函数，该函数接受两个Foo对象并将第一个对象的元素添加到第二个对象中，如下所示：

MyFunction(const Foo& a, Foo* b) {
  for (int i = 0; i < a.bar_count(); i++) {
    b->Bar(i) = b->HasBar(i) ? Average(a.Bar(i), b->Bar(i)) : a.Bar(i);
  }
}

显然，这是一个玩具的例子，但我的观点是：MyFunction、a和b的名字应该是什么？我的第一个想法是类似MergeFoo但后来我不确定如何命名参数，因为我最好的想法是像merger和mergee这样的东西，这似乎很愚蠢。

a、b 和 MyFunction 的好名称是什么，以便 API 对此功能的用户一目了然？

我会称它们为merge()，src和dest，但当然还有其他好名字。

from和into似乎它们可能是合适的，但就我个人而言，我会将其作为您Foo类的方法。这意味着没有模棱两可的参数顺序，没有不方便的参数命名等...... Foo::merge(const Foo& other_foo)

顺便说一下，我会考虑称它为不同的东西。对我来说，合并表明最终结果是原始组件的集合并集，而您正在执行某种移动平均计算或类似操作。我没有一个好的替代名称可以建议，因为我不知道Foo、Bar或Average的实际目的或功能，所以这必须由你决定！

这

看起来像是一个就地zip然后是平均水平的操作。 （ http://docs.python.org/2/library/functions.html#zip ）

因此，与其进行索引访问，不如使用迭代器访问。 然后 http://www.boost.org/doc/libs/1_41_0/libs/iterator/doc/zip_iterator.html 压缩两者，然后 http://www.boost.org/doc/libs/1_35_0/libs/iterator/doc/transform_iterator.html 结果转换回第一个迭代器（条件平均值）。

用C++写这确实有点烦人。

迭代器超过boost::optional<bar>，压缩成一对，然后通过取一个或平均（如果两者都存在）产生一个boost::optional<bar>。

那么，left.ZipThenAverageInPlace( right )？

一个常见的C++命名约定是lhs和rhs。这意味着左侧和右侧。通常，如果函数修改其参数之一，那将是 lhs .所以在你的例子中：

void MyFunction(Foo& lhs, const Foo& rhs);

请注意，顺序是从您的示例中交换的。

例如，

请参阅提升库，例如：http://www.boost.org/doc/libs/1_52_0/libs/utility/operators.htm

维护者对容器类对象的"合并"的期望是根据合并的功能。 您要完成的是在名为"average"的二元运算符的名为"average"的 STL 中完成的。 如果您不使用 STL 算法，我会将函数命名为"average"以避免"合并"

在考虑了所有选项后，我决定最好的选择是 AverageBarsInPlace(const Foo& new_bars, Foo* existing_bars); .我喜欢Yakk的"InPlace"后缀。我同意 May 的回应，即"除非它实际上在进行合并，否则不要称其为Merge"。

然而，我对这个问题缺乏共识的真正收获是：这个函数的范围定义不明确。我应该将函数分解为更具凝聚力的块，例如一个函数用于合并，另一个函数用于执行平均。

可以这样定义一个合并函数：一个实例吸收另一个实例释放的元素。因此，这导致我使用参数名称absorber和releaser

在 PHP 中，这会导致以下函数定义：

public function merge(ClassName $absorber, ClassName $releaser): void

相关文章：