为什么在 C + + 类中对成员变量使用前缀

其他人则试图强制使用 此-> 成员每当成员 使用变量

通常是 因为没有前缀。编译器需要足够的信息来解析有问题的变量，无论是因为前缀而使用的唯一名称，还是通过 this关键字。

所以，是的，我认为前缀仍然有用。比如，我更喜欢输入“ _”来访问成员，而不是输入“ this->”。

我不能说它有多普遍，但就我个人而言，我总是(并且一直)在我的成员变量前面加上‘ m’。例如:

class Person {
....
private:
std::string mName;
};

这是我使用的唯一一种前缀形式(我非常反对使用匈牙利命名法) ，但这些年来它一直对我很有帮助。顺便说一句，我通常不喜欢在名称(或其他任何地方)中使用下划线，但预处理器宏名称例外，因为它们通常都是大写。

那些会议就是这样。大多数商店使用代码约定来简化代码的可读性，因此任何人都可以轻松地查看一段代码，并快速地破译公共成员和私有成员之间的信息。

当您有一个大的方法或代码块时，立即知道是使用局部变量还是成员是很方便的。这是为了避免错误和更好的清晰度！

我不认为一种语法比另一种语法有实际价值。正如您所提到的，所有这些都归结为整个源文件的一致性。

我发现这些规则唯一有趣的地方是当我需要两个同名的东西时，例如:

void myFunc(int index){
this->index = index;
}


void myFunc(int index){
m_index = index;
}

我用它来区分两者。另外，当我包装调用时，比如来自 windows Dll 的调用，来自 Dll 的 RecvPacket (...)可能会包装在我的代码中的 RecvPacket (...)中。在这些特殊情况下，使用像“ _”这样的前缀可能会使两者看起来很相似，很容易区分哪一个是哪一个，但是对于编译器来说是不同的

使用前导下划线时必须小心。保留单词中大写字母前的前导下划线。 例如:

福

是的

都是保留词

(咒语)

我..

不是。还有一些情况下，不允许在小写字母之前加上前导下划线。在我的具体案例中，我发现 _ L 碰巧被 Visual C + + 2005保留，这种冲突产生了一些意想不到的结果。

我对标记局部变量是多么有用持观望态度。

这里有一个关于保留哪些标识符的链接: 在 C + + 标识符中使用下划线的规则是什么？

其他语言将使用编码约定，他们只是倾向于不同。例如，C # 可能有两种不同的风格，一种是 C + + 方法(_ variable、 mVariable 或其他前缀，比如匈牙利命名法) ，另一种是我称之为 StyleCop 的方法。

private int privateMember;
public int PublicMember;


public int Function(int parameter)
{
// StyleCop enforces using this. for class members.
this.privateMember = parameter;
}

最后，它变成了人们所知道的和看起来最好的。我个人认为代码在没有匈牙利命名法的情况下更容易阅读，但是如果附加了匈牙利命名法，找到带智能感知的变量就会变得更容易。

在我上面的示例中，您不需要成员变量的 m 前缀，因为您的用法前面加上了这个。在编译器强制的方法中指示同样的事情。

这并不一定意味着其他方法是坏的，人们坚持什么工作。

我的天，这是私人恩怨。我一个前缀都没加。无论如何，如果代码是公共的，我认为它应该更好地有一些前缀，这样它可以更具可读性。

大公司经常使用自己的所谓“开发者规则”。
顺便说一句，我见过的最有趣也是最聪明的是干吻(不要重复自己。保持简单，愚蠢) : -)

我认为，如果需要前缀来区分类成员与成员函数参数和局部变量，那么要么函数太大，要么变量的名称不好。如果它不适合在屏幕上，所以你可以很容易地看到什么是什么，重构。

考虑到它们通常在远离使用它们的地方声明，我发现全局常量(和全局变量，尽管 IMO 很少需要使用它们)的命名约定是有意义的。但除此之外，我觉得没什么必要。

也就是说，我过去常常在所有私有类成员的末尾放置下划线。由于我的所有数据都是私有的，这意味着成员有一个尾随下划线。我通常不再在新的代码库中这样做，但是因为作为一个程序员，您大多数使用旧的代码，所以我仍然经常这样做。我不确定我对这个习惯的容忍是因为我过去总是这样做，现在仍然经常这样做，还是因为它真的比标记成员变量更有意义。

正如其他人已经说过的，重要的是要口语化(将命名样式和约定适应于您正在编写的代码基)并保持一致。

多年来，我一直致力于开发一个大型代码库，该代码库既使用“ this->”约定，也使用 后缀下划线表示成员变量。多年来，我也参与过一些小型项目，其中一些没有任何命名成员变量的约定，另一些则有不同的命名成员变量的约定。在那些较小的项目中，我一直发现那些缺乏任何惯例的项目是最难迅速投入和理解的。

我对命名很敏感。我会为一个类或变量的名字而苦恼，以至于，如果我不能想出一些我觉得“好”的东西，我会选择给它起一些毫无意义的名字，然后提供一个注释来描述它的真实面目。那样的话，至少这个名字的意思和我想要表达的完全一样——不多也不少。通常，在使用它一段时间后，我会发现 真的应该是什么名字，然后可以返回并适当地修改或重构它。

关于 IDE 完成这项工作的最后一点——这非常好，但是在我执行最紧急工作的环境中，IDE 通常是不可用的。有时，此时唯一可用的就是“ vi”的副本。此外，我还看到过许多 IDE 代码完成导致愚蠢行为的案例，例如名称中的错误拼写。因此，我倾向于不依赖 IDE 拐杖。

由于内存管理，区分成员变量和局部变量很有用。一般来说，堆分配的成员变量应该在析构函数中销毁，而堆分配的本地变量应该在该范围内销毁。对成员变量应用变数命名原则有助于正确的内存管理。

C + + 成员变量前缀的最初想法是存储编译器不知道的其他类型信息。例如，可以有一个字符串是固定长度的字符，另一个字符串是变量，以’0’结尾。对于编译器来说，它们都是 char *，但是如果你试图从一个文件复制到另一个文件，你就会遇到很大的麻烦。所以，我第一时间想到,

Char * aszFred = “嗨，我是个空终止字符串”;
Char * arrWilma = {‘ O’，‘ o’，‘ p’，‘ s’} ;

其中“ asz”表示这个变量是“ ascii 字符串(以零结尾)”，“ arr”表示这个变量是一个字符数组。

然后奇迹发生了，编译器会非常满意这句话:

Strcpy (arrWilma，aszFred) ;

但是你，作为一个人，可以看着它说“嘿，这些变量不是真正的同一类型，我不能这样做”。

不幸的是，很多地方都使用标准，比如成员变量使用“ m _”，整数使用“ i”，字符指针使用“ cp”。换句话说，它们是在复制编译器所知道的内容，同时使代码难以阅读。我认为这种有害的做法应该被法律禁止，并受到严厉的惩罚。

最后，我要提到两点:

• 明智地使用 C + + 特性可以让编译器知道必须用原始的 C 样式变量编码的信息。可以创建只允许有效操作的类。这应该尽可能实际地去做。
• 如果代码块太长，以至于在使用变量之前忘记了变量的类型，那么它们就是 方式太长。不要用名字，重新组织。

我更喜欢后缀下划线，比如:

class Foo
{
private:
int bar_;


public:
int bar() { return bar_; }
};

我通常不为成员变量使用前缀。

我过去常常使用 m前缀，直到有人指出“ C + + 已经有一个用于成员访问的标准前缀: this->。

这就是我现在用的。也就是说，当有模棱两可的时候，我添加了 this->前缀，但通常不存在歧义，我可以直接引用变量名。

对我来说，这是两全其美的。我有一个前缀，我可以使用，当我需要它，我可以自由离开它，只要有可能。

当然，显而易见的反对意见是“是的，但是你不能一眼看出变量是否是类成员”。

我说“那又怎样?”？如果您需要知道这一点，那么您的类可能有太多的状态。或者函数过于庞大和复杂。”。

在实践中，我发现这种方法非常有效。作为额外的好处，它允许我轻松地将一个局部变量提升为类成员(或者反过来) ，而不必重命名它。

最棒的是，它始终如一！我不需要做任何特别的事情或者记住任何约定来保持一致性。

顺便说一下，你的 不应该为你的类成员使用前导下划线。您会不舒服地接近实现保留的名称。

标准保留所有以双下划线或大写字母跟随的下划线开头的名称。它还保留以单个下划线 在全局命名空间中开头的所有名称。

因此，类成员使用前导下划线后跟小写字母是合法的，但迟早你会对以大写字母开头的标识符做同样的事情，否则就会违反上述规则之一。

所以避免使用前导下划线更容易。如果希望在变量名中编码作用域，请使用后缀下划线或 m_或仅使用 m前缀。

我们的项目总是使用“ its”作为成员数据的前缀，使用“ the”作为参数的前缀，没有局部变量的前缀。这有点矫揉造作，但是它被我们系统的早期开发人员采用了，因为他们认为它被我们当时使用的一些商业源代码库(XVT 或 RogueWave ——也许两者都有)作为惯例使用。你会得到这样的结果:

void
MyClass::SetName(const RWCString &theName)
{
itsName = theName;
}

我认为确定前缀范围的最大原因(没有其他原因——我讨厌匈牙利命名法)是，它可以防止你在编写代码时遇到麻烦，因为你以为你引用的是一个变量，但实际上你引用的是另一个在本地范围内定义的同名变量。它还避免了使用变量名来表示相同的概念，但使用不同的作用域的问题，如上面的示例所示。在这种情况下，无论如何您都必须为参数“ theName”想出一些前缀或不同的名称——为什么不制定一个适用于所有地方的一致规则呢。

仅仅使用这个-> 还不够好-我们对减少模糊性的兴趣不如对减少编码错误的兴趣，并且使用局部作用域标识符掩盖名称可能是一件痛苦的事情。当然，一些编译器可以选择对在更大范围内隐藏名称的情况提出警告，但是如果您使用的是大量的第三方库，而这些第三方库恰好为未使用的变量选择了名称，这些名称偶尔会与您自己的名称发生冲突，那么这些警告可能会成为一个麻烦。

至于它/它本身——老实说，我发现它比下划线更容易输入(作为一个触摸式打字员，我尽可能避免使用下划线——过多地延伸主行) ，而且我发现它比神秘的下划线更易读。

我之所以使用它，是因为 VC + + 的智能感知无法判断何时显示私有成员。唯一的指示是 Intellisense 列表中字段图标上的一个小“锁”符号。它只是使识别私有成员(字段)变得更加容易。老实说，这也是 C # 的一个习惯。

class Person {
std::string m_Name;
public:
std::string Name() { return m_Name; }
void SetName(std::string name) { m_Name = name; }
};


int main() {
Person *p = new Person();
p->Name(); // valid
p->m_Name; // invalid, compiler throws error. but intellisense doesn't know this..
return 1;
}

CodeComplete 建议成员变量使用 m _ varname。

虽然我从来不认为 m _ 符号有用，但是在构建标准时，我会考虑 McConnell 的意见。

一些响应关注重构，而不是命名约定，作为提高可读性的方法。我不认为一个可以取代另一个。

我知道有些程序员不喜欢使用局部声明; 他们喜欢将所有声明放在一个块的顶部(如 C 语言) ，这样他们就知道在哪里可以找到它们。我发现，在作用域允许的情况下，在首次使用变量的地方声明变量，可以减少我向后查找声明的时间。(对我来说，即使是小函数也是如此。)这让我更容易理解我正在看的代码。

我希望这与成员命名约定之间的关系足够清楚: 当成员前缀一致时，我根本不必回头查看; 我知道声明甚至不会出现在源文件中。

我肯定我一开始并不喜欢这些款式。然而，随着时间的推移，在一贯使用它们的环境中工作，我优化了自己的思维，以利用它们的优势。我认为有可能许多现在对它们感到不舒服的人也会更喜欢它们，因为它们的用法是一致的。

我全力支持 前缀做得很好。

我认为(系统)匈牙利命名法对大多数前缀得到的“坏名声”负有责任。

这种表示法在强类型语言中很大程度上是没有意义的，例如在 C + + “ lpsz”中，它告诉你你的字符串是一个指向空结束字符串的长指针，当: 分段体系结构是古老的历史，C + + 字符串是通常约定的指向空结束字符数组的指针，并且知道“ customerName”是一个字符串并不是真的那么困难！

然而，我确实使用前缀来指定变量的 用途(本质上是“ Apps 匈牙利语”，尽管我更喜欢避免使用匈牙利语，因为它与匈牙利语系统有着糟糕而不公平的联系) ，这是一种非常方便的 节省时间和 减少虫害方法。

我用:

• M 为会员
• C 表示常量/readonly
• P 表示指针(pp 表示指针到指针)
• V 代表不稳定
• 是静电干扰
• I 表示索引和迭代器
• 事件

如果我希望使 类型清晰，我会使用标准的后缀(例如 List、 ComboBox 等)。

这使得程序员在看到/使用变量时能够意识到它的 用途。可以说，最重要的情况是“ p”表示指针(因为用法从 var 改变)。指向 var-> ，并且您必须更加小心地使用指针-NULL、指针算法等) ，但是其他所有指针都非常方便。

例如，您可以在一个函数中以多种方式使用相同的变量名: (这里是一个 C + + 示例，但它同样适用于多种语言)

MyClass::MyClass(int numItems)
{
mNumItems = numItems;
for (int iItem = 0; iItem < mNumItems; iItem++)
{
Item *pItem = new Item();
itemList[iItem] = pItem;
}
}

你可以在这里看到:

• 成员和参数之间没有混淆
• 索引/迭代器和项之间没有混淆
• 使用一组清晰相关的变量(项目列表、指针和索引) ，以避免“ count”、“ index”等通用(模糊)名称的许多缺陷。
• 前缀比“ itemIndex”和“ itemPtr”等替代词减少了键入(更短，并且在自动完成时效果更好)

“ iName”迭代器的另一个伟大之处在于，我从不用错误的索引来索引一个数组，如果我在另一个循环中复制一个循环，我就不必重构一个循环索引变量。

比较一下这个不切实际的简单例子:

for (int i = 0; i < 100; i++)
for (int j = 0; j < 5; j++)
list[i].score += other[j].score;

(这很难理解，而且经常导致在用“ j”的地方使用“ i”)

与:

for (int iCompany = 0; iCompany < numCompanies; iCompany++)
for (int iUser = 0; iUser < numUsers; iUser++)
companyList[iCompany].score += userList[iUser].score;

(这样更具可读性，并且消除了所有关于索引的混淆。使用现代 IDE 中的自动完成功能，这也是快速且易于输入的)

下一个好处是可以理解代码段 不需要任何上下文。我可以将两行代码复制到一封电子邮件或一个文档中，任何阅读该代码片段的人都可以区分所有成员、常量、指针、索引等。我不需要加上“哦，要小心，因为‘ data’是一个指向指针的指针”，因为它叫做‘ ppData’。

出于同样的原因，我不必为了理解它而把眼睛从一行代码中移开。我不必搜索代码来查找“ data”是否是局部的、参数的、成员的或常量的。我不必把手移到鼠标上，这样我就可以把鼠标悬停在“ data”上，然后等待弹出一个工具提示(有时从来不会出现)。因此，程序员可以更快地阅读和理解代码 意义重大，因为他们不会浪费时间上下搜索或等待。

(如果你不认为你浪费时间上下搜索来解决问题，找到一些你一年前写的代码，而且还没有看过 打开文件，跳到一半而不读它。 看看你能从这一点读多远，在你不知道是否 某物是一个成员，参数或局部。现在跳转到另一个随机 这是我们单身时一整天都在做的事情 通过别人的代码或试图理解如何 调用它们的函数)

“ m”前缀还避免了(恕我直言)丑陋和冗长的“ this->”表示法，以及它所保证的不一致性(即使你很小心，通常也会在同一个类中结束“ this-> data”和“ data”的混合，因为没有什么强制名称的一致拼写)。

‘ this’符号是用来解析 模棱两可的——但是为什么有人会故意编写模棱两可的代码呢？模糊 威尔迟早会导致 bug。在某些语言中，“ this”不能用于静态成员，因此必须在编码风格中引入“特殊情况”。我更喜欢有一个简单的编码规则，适用于所有地方-明确的，明确的和一致的。

最后一个主要好处是智能感知和自动完成。尝试在 Windows 窗体上使用 Intellisense 来查找事件——您必须滚动数百个神秘的基类方法，这些方法永远不需要调用来查找事件。但是，如果每个事件都有一个“ e”前缀，那么它们将自动被列在“ e”下面的一个组中。因此，前缀可以对智能感知列表中的成员、常量、事件等进行分组，从而更快、更容易地找到所需的名称。(通常，一个方法可能有大约20-50个值(局部变量、参数、成员、常量、事件) ，可以在其作用域内访问。但是在输入前缀之后(我现在想使用一个索引，所以我输入‘ i。.’) ，我只有2-5个自动完成的选项。前缀和有意义的名字是人们“额外输入”的原因，这大大减少了搜索空间，显著加快了开发速度)

我是一个懒惰的程序员，上面的约定为我节省了很多工作。我可以编码更快，犯的错误也少得多，因为我知道应该如何使用每个变量。

反对

那么，缺点是什么呢? 反对前缀的典型论据是:

• “前缀方案是坏的/邪恶的”。我同意“ m _ lpsz”及其类似的词是考虑不周和完全无用的。这就是为什么我建议使用设计良好的符号来支持您的需求，而不是复制不适合您的上下文的内容。(使用正确的工具完成工作)。

• “如果我改变了某事物的用法，我必须重新命名它” 。是的，当然需要，这就是重构的意义所在，也是为什么 IDE 拥有重构工具来快速、轻松地完成这项工作的原因。即使没有前缀，改变变量的用法几乎肯定意味着要改变它的名称 应该。

• “前缀只会让我迷惑”。每个工具都是如此，直到你学会如何使用它。一旦你的大脑习惯了命名模式，它就会自动过滤掉这些信息，你就不会再介意前缀的存在了。但是你必须在一两个星期内坚定地使用这样的方案，才能真正变得“流利”。这时，许多人看着旧代码，开始想知道他们是如何管理 没有一个好的前缀方案的。

• “我只要看看代码就可以解决这个问题” 。是的，但是你不需要浪费时间在代码的其他地方寻找或者记住它的每一个小细节，当答案就在你的眼睛已经关注的地方。

• 只要等待变量 上弹出一个工具提示，就可以找到其中的一些信息。是的。在支持的情况下，对于某些类型的前缀，当您的代码编译干净时，经过一段时间的等待，您可以通读一段描述，并找到前缀可以立即传达的信息。我认为前缀是一种更简单、更可靠和更有效的方法。

• “更多的是打字”。真的吗？多一个角色？或者说，使用 IDE 自动完成工具，通常会减少输入，因为每个前缀字符都会显著缩小搜索空间。按下“ e”，你的类中的三个事件就会以智能方式弹出。按“ c”，列出了五个常量。

• “我可以用 this->代替 m” 。不，你可以的。但那只是一个更加丑陋和冗长的前缀！只是它带有更大的风险(特别是在团队中) ，因为对编译器来说它是 可以选择，因此它的使用经常是不一致的。另一方面，m简洁、清晰、明确，而且不是可选的，所以使用它更难犯错误。