Question

class C {
 private:
  int member_; // here is the underscore I refer to.
}

Google Style Guide和Geosoft's C++ Style Guide建议使用此下划线。

我知道有不同的意见和口味。

我想问一下使用它或被迫使用它的人是否认为它们对它们有益，中性或有害。为什么？

以下是我的回答：

我理解它背后的动机，但它并不能说服我。我尝试了它，我得到的只是整个类的一点点混乱，但构造函数中的成员初始化更简单。我没有遇到下划线帮助私有成员变量和其他变量之间有所区别的情况（除了提到的初始化）。

从这个角度来看，我觉得这种风格很有害。

Answer 1

因为没有人提到它：向成员变量添加下划线允许您使用变量的“概念”名称命名getter和setter。

例如：

class MyClass
{
   int someMember_;

public:
   int someMember() const { return someMember_; }
   void someMember( int newValue ) { someMember_ = newValue; }
};

不是我使用这种风格。

Answer 2

如果你需要这个下划线以告诉类成员来自其他变量，你可能有太大的成员函数来立即看到什么是变量/参数。

我仍然喜欢它，因为它经常简化成员函数参数命名：

class person
{
public:
  person(const std::string& first_name, const std::string& last_name)
    : first_name_(first_name), last_name_(last_name) {}

  // .......

private:
  std::string first_name_;
  std::string last_name_;
};

Answer 3

我使用“m_”作为普通成员变量的前缀，使用“s_”作为静态成员变量。所以范围直接可见。

Answer 4

对我来说，这种装饰成员变量的好处是它适用于文本编辑器的自动完整功能。有一个前缀装饰需要你在可以猜测你的意思之前输入更多的字符。

Answer 5

我认为区分类变量和本地变量（以及真正需要的全局变量）非常重要。你是如何做到的，并不重要 - 只要保持一致。

class Foo
{
  int mMember;
  int member_;
  int _member;
  int m_Member;
};

所有款式都能为您提供所需的信息。只要你一直保持同样的风格，没问题。有时其他人需要使用您的代码（例如，当您创建库，或者您与社区合作时）。那么在C ++社区中坚持使用最常用的样式可能是一个好主意。

抱歉 - 我无法回答那种风格。

Answer 6

我在C ++编码日（80年代末，90年代初）独立地想出了这种风格，因为我遇到了几个令人困惑的情况，我不得不继续回到类标题来确定哪个变量真的是成员变量

一旦我开始看到其他人的C ++代码做同样的事情，我感到非常欣慰的是我注意到了其他人所遇到的问题，而且我为自己采用的解决方案是其他人也想到的。

它不常用，但它相当无害，当它有用时，它非常有用。

这也是我真的讨厌m_风格的原因。这不是无害的，我认为增加的丑陋不值得受益。

我对文件范围静态变量和不是常量的类静态变量使用S_前缀。它们有点像全局变量，我认为它们的使用应该大声发出信号。

Answer 7

这基本上是一个宗教论点，所以你永远不会就这种风格达成共识。 FWIW，我将这种风格用于我的成员变量，原因是其他人已经说过，例如：

class Foo
{
public:
  Foo(std::string name, int age) :
    name_(name),
    age_(age)
  {
  }

  std::string name() const { return name_; }
  void name(const std::string& name) { name_ = name; }

  int age() const { return age_; }
  void age(int age) { age_ = age; }
private:
  std::string name_;
  int age_;
};

只要采用你满意的东西并坚持下去。

Answer 8

我们在工作中讨论了这个问题，但是使用Java编程。但我认为这也适用于C ++。我的回答是IDE有一个方便的着色类成员变量的功能。在Eclipse中，它们变成蓝色。下划线是多余的。正如另一张海报所说，“EW，匈牙利疣!!”。 1980年召集并希望它回归匈牙利语。

Answer 9

我们关注possibility.com's C++ coding standard，它说成员变量的前缀为'm'，但我也在Google的样式指南下做了一些工作。

就像你说的那样，它并不是绝对必要的，特别是如果你有一个IDE为成员变量分配不同的语法高亮。但是，我认为一些类似的一致命名方案，让你一眼就看出一个变量是否是成员变量，是非常值得的：

简化参数命名，如sbi的答案，是一个好处。
无论您选择哪种风格，一致的编码风格都很重要。理想情况下，团队中的每个人都会使用相同的编码风格，因此您无法一眼就看出谁编写了一段代码。这有助于将新开发人员带入团队并使用敏捷实践（例如无代码所有权），对于可能吸引各种贡献的开源项目更为重要。
最重要的是，可读性可以大大受益于让所有代码都遵循相当严格的样式，这样就可以清除像这样的标识符类型。能够一眼就知道变量是成员并且能够通过查看局部变量的声明来判断的差异可能很小，但是遵循良好的编码标准会产生很多小的差异在整个代码体系中都是如此，它可以在代码易于遵循的程度以及在不熟悉的代码部分中开始使用它是多么容易。

（你提到过你尝试过这种风格，但是如果它仅用于代码的一部分而且仅用于你已经熟悉的代码，那么就很难看到遵循这样的编码风格的可读性好处对于整个代码库可以带来。）

所有这些都是根据我的经验，您的里程可能会有所不同等等。

Answer 10

还有一个“风格”，它建议将类成员声明如下：

class Foo{
    int m_value;
public:
     //...
};

我发现它可用。但这只是我的观点。

Answer 11

我同意托比亚斯的观点，即突出类变量对某些约定 - 无论可能是什么 - 都有好处。另一方面，我总是发现这些约定使代码“流动”不太好。它更容易阅读“totalPrice = productPrice + salesTax”，然后“m_totalPrice = l_productPrice + l_salesTax”或其他任何内容。

最后，我更喜欢让所有的字段名称都未修饰，并且没有足够的类变量来跟踪它们并不是问题。在构造函数和setter中，我在参数上添加了前缀或后缀，或者在Java中我通常将类变量与“this。”区分开来，如：

public Foo(int bar)
{
  this.bar=bar;
}

（你能用C ++做到吗？我已经记不起来了。）

Answer 12

我同意你的观点，下划线变量后缀不是理想的编码风格，在构造函数中添加一点复杂性比在整个类中增加更多复杂性要好。

前几天，我看了一个旧的Java项目，其中我将下划线后缀应用于变量名称，我发现它确实使得阅读代码变得更加困难。这不是很难习惯，但我发现它有点分散注意力而没有增加任何实际好处。

Answer 13

我总是希望将类成员与变量区分开来。我使用_作为成员的前缀，并且个人而言，这使代码保持清洁和可读。使用编辑器的intellisense，前缀可以正常工作。使用m_或s_进行前缀非常有用，但对我来说看起来很难看。

使用下划线后缀对会员有益吗？

13 个答案: