Question

对于那些使用m_foo或foo_等特殊符号命名成员变量的人，如何为ctors和setter命名参数？

到目前为止我尝试过的一些选项......

Obj(int foo) : foo(foo) { }
void set_foo(int foo) { this->foo = foo; }

Obj(int _foo) : foo(_foo) { }
void set_foo(int _foo) { foo = _foo; }

Obj(int a_foo) : foo(a_foo) { } // a for "argument"
void set_foo(int a_foo) { foo = a_foo; }

Obj(int init_foo) : foo(init_foo) { }
void set_foo(int new_foo) { foo = new_foo; }

Answer 1

我正在使用foo_，它比_foo更好，因为它不会与特定于实现的函数名称和关键字冲突。

Answer 2

我要去

Obj(int foo) : mFoo(foo) { }
void setFoo(int foo) { mFoo = foo; }

在我的课程中。对于copy constructors和operator =，我倾向于称之为

Obj(Obj const& that):mFoo(that.mFoo) { }

对于运营商来说，我要去

Obj operator+(Obj const& lhs, Obj const& rhs) { ... }

因为那些是 l eft h 和 s ide以及 r ight h < / strong>和 s ide。

Answer 3

我倾向于遵循正在设置的参数的第一个字母，并消除歧义......

void setFoo(int f) { foo = f; }

对于一个简单的setter，对于一个变量，它非常清楚。

另外，我经常这样做

int setFoo(const int f) { foo = f; }

所以我可以把事情串起来。

Answer 4

我避免（通过避免意味着永远不会使用）下划线作为任何标识符的第一个字符。我知道它的矫枉过正但值得付出努力。

阅读本文： What are the rules about using an underscore in a C++ identifier?

虽然不是规则，但我限制使用下划线并且更喜欢驼峰情况以使我的变量可读。但这只是个人偏好，我不介意阅读使用它的代码。

另外，我从不将参数命名为与我的成员变量相同。编译器不会帮助你捕获它可以生成的错误类型（这就是让编译器完成真正的工作，这样你就可以完成编译器不能做的富有表现力的工作）。

int X::setWork(int work)
{
    this->work = work;  // OK. But more Java like.

    work = work;        // Compiler won't see that problem.
}

int X::setWork(int newWork)
{
    work = newWork;    // A bit harder to get wrong.
}

Answer 5

我总是这样做：

Obj(int foo) : foo(foo) {}

我曾经玩过有趣的符号游戏，直到有一次我被这个击中：

Obj(Bar& b) : b_(b_) {}

你能看到错误吗？（是的，b_是私有成员引用变量）。它没有警告编译。花了我3天的调试时间（我当时是一名绿色程序员）。

现在我总是使用相同的名称来避免拼写错误（以及随后的崩溃）。初始化列表中没有歧义。这部分语言是为这种情况设计的，所以要充分利用它。

Answer 6

我总是选择Param或Arg后缀，但只有在需要消除歧义时才会使用。

Obj(int fooArg) : foo(fooArg)

Answer 7

对于课程：

Obj(int foo) : _foo(foo) {};

结构：

obj_t(int foo_) : foo(foo_) {};

设置器：

Obj.setFoo(int foo) { _foo = foo; }

我对使用lhs和rhs进行操作员调用非常感兴趣。

我对类成员函数使用camelCase，对结构域和方法使用names_with_underscores。

Answer 8

我过去遵循Microsoft m_前缀成员变量的惯例，如m_foo。在我当前的公司，约定是成员变量的尾随下划线：foo_。

通常，如果您自己工作，那么请使用您喜欢的任何惯例。如果您在团队中工作，请使用团队同意的任何内容。代码库中的整体一致性是重要的，而不是特定的约定。

Answer 9

作为惯例，第二号有问题，尽管在你的情况下它可能是无害的。具有前导下划线后跟大写字符的名称将保留用于实现，并且具有前导下划线的所有名称都保留在全局上下文中。如果你从来没有以大写字母开头的类成员（我不这样做），你就可以安全地使用所示的约定（仅使用_foo作为函数参数），但我不喜欢任何接近极限的命名约定。

Answer 10

我将实际成员命名为尾随下划线，所以我这样做：

Foo(int bar) : bar_(bar) { }

原因是我可以使用getter函数而不使用getBar（）（bar（）更好）。

Answer 11

我这样做：

obj(int foo) : _foo(foo) { }
int foo() const { return _foo; }
void foo(int value) { _foo = value; }

这里唯一的技巧是确保下划线后面的字母是小写的。但是，我在任何地方都避免使用标识符名称的大写，因为它与标准库使用的约定不一致（对所有标识符使用foo_bar_baz）。

Answer 12

我按照 Google C++ Style Guide

进行操作

变量名都是小写的，单词之间有下划线。类成员变量具有尾随下划线。例如：my_exciting_local_variable，my_exciting_member_variable _。

ctors和setter params的命名约定

12 个答案: