为什么在 C++ 中的数据成员上使用像 m_ 这样的前缀 课程？

Question

许多 C++ 代码使用语法约定来标记数据成员。 常见的示例包括

• 用于公共成员的 m_memberName （其中完全使用公共成员）
• _memberName 用于私有成员或所有成员

其他人尝试使用 this->member 强制执行 每当使用数据成员时。

根据我的经验，大多数较大的代码库都无法一致地应用这些规则。

在其他语言中，这些约定远没有那么普遍。 我只是偶尔在 Java 或 C# 代码中看到它。 我想我从未在 Ruby 或 Python 代码中见过它。 因此，更现代的语言似乎有一种趋势，即不对数据成员使用特殊标记。

这个约定现在在 C++ 中仍然有用吗？或者它只是一个不合时宜的东西，特别是因为它在各个库中的使用如此不一致？ 其他语言难道没有表明可以不用成员前缀吗？

Answer 1

其中许多惯例都是在没有成熟编辑的时代产生的。 我建议使用合适的 IDE，它允许您为每种变量着色。 颜色比任何前缀都更容易识别。

如果您需要获得有关变量的更多详细信息，任何现代 IDE 都应该能够通过将插入符号或光标移到变量上来向您显示。 如果您以错误的方式使用变量（例如带有 . 运算符的指针），无论如何您都会收到错误。

Answer 2

根据联合打击战斗机 C++ 编码标准（2005 年 12 月）：

AV 规则 67

公共和受保护的数据只能用于
结构——而不是类。 理由：一个类能够维持它的
通过控制对其数据的访问来保持不变。 然而，一个类不能
如果这些成员是非私有的，则控制对其成员的访问。 因此所有
类中的数据应该是私有的。

因此，“m”前缀变得无用，因为所有数据都应该是私有的。

但在指针前使用 p 前缀是一个好习惯，因为它是一个危险的变量。

Answer 3

用结构体包装所有私有数据

class Demo {
public:
    Demo() {
        self.name = "Harry Porter";
        self.age = 18;
    }
protected:
    struct self_type {
        std::string name;
        int age;
    } self = {};
};

Answer 4

您永远不需要这样的前缀。 如果这样的前缀为您提供了任何优势，那么您的编码风格通常需要修复，并且并不是前缀使您的代码变得不清晰。 典型的错误变量名称包括“other”或“2”。 您不需要通过要求它是 mOther 来解决这个问题，您可以通过让开发人员考虑该变量在该函数的上下文中正在做什么来解决它。 也许他指的是remoteSide、newValue、secondTestListener 或该范围内的其他内容。

这是一种有效的不合时宜的做法，但仍然传播得太远。 停止为变量添加前缀，并为它们提供适当的名称，其清晰度反映了它们的使用时间。 最多 5 行，您可以将其称为“i”而不会混淆； 超过 50 行，你需要一个很长的名字。

Answer 5

我几乎从不在变量名前面使用前缀。 如果您使用足够好的 IDE，您应该能够轻松重构和查找参考。 我使用非常清晰的名称，并且不担心变量名称很长。 对于这种哲学，我也从未遇到过范围问题。

我唯一一次使用前缀是在签名行上。 我将在方法的参数前加上 _ 前缀，这样我就可以围绕它们进行防御性编程。

Answer 6

Code Complete 建议使用 m_varname 作为成员变量。

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

Answer 7

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

Answer 8

我使用 m_ 作为成员变量只是为了利用 Intellisense 和相关 IDE 功能。 当我编写类的实现时，我可以输入 m_ 并查看包含所有 m_ 成员组合在一起的组合框。

但当然，没有 m_ ，我也可以生活。 这只是我的工作风格。

Answer 9

我喜欢变量名只赋予它们所包含的值一个含义，而将它们的声明/实现方式保留在名称之外。 我想知道这个值意味着什么。 也许我已经完成了超过平均数量的重构，但我发现在名称中嵌入某些内容的实现方式会使重构变得比实际需要的更加乏味。 指示对象成员声明位置或方式的前缀是特定于实现的。

color = Red;

大多数时候，我不在乎 Red 是枚举、结构还是其他什么，如果函数太大以至于我不记得 color 是在本地声明的还是成员，那么可能是时候打破了将函数分解为更小的逻辑单元。

如果您的圈复杂度如此之大，以至于您无法跟踪代码中发生的情况，而无需在事物名称中嵌入特定于实现的线索，那么您很可能需要降低函数/方法的复杂性。

大多数情况下，我只在构造函数和初始化程序中使用“this”。

Answer 10

在 python 中，前导双下划线用于模拟私有成员。 有关更多详细信息，请参阅 这个答案

Answer 11

我认为，如果需要前缀来区分类成员、成员函数参数和局部变量，要么是函数太大，要么是变量命名不当。 如果它不适合屏幕，以便您可以轻松地看到是什么，请重构。

鉴于它们通常是在远离它们使用的地方声明的，我发现全局常量（和全局变量，尽管在我看来很少需要使用它们）的命名约定是有意义的。 但除此之外，我认为没有太大必要。

也就是说，我曾经在所有私有类成员的末尾加下划线。 由于我的所有数据都是私有的，这意味着成员有一个尾随下划线。 我通常不再在新的代码库中这样做，但由于作为一名程序员，您主要使用旧代码，因此我仍然经常这样做。 我不确定我对这个习惯的容忍是否来自于我以前总是这样做并且现在仍然定期这样做，或者它是否真的比成员变量的标记更有意义。

Answer 12

我使用它是因为 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;
}

Answer 13

我们的项目一直使用“its”作为成员数据的前缀，使用“the”作为参数的前缀，而没有本地变量的前缀。 这有点可爱，但它被我们系统的早期开发人员采用，因为他们看到我们当时使用的一些商业源库（XVT 或 RogueWave - 也许两者都）将其用作约定。 所以你会得到这样的结果：

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

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

只需使用这个-> 还不够好 - 我们对减少歧义并不像对减少编码错误那么感兴趣，并且用本地范围的标识符屏蔽名称可能会很痛苦。 诚然，某些编译器可能可以选择在您在更大范围内屏蔽名称的情况下发出警告，但如果您正在使用大量第三方库，而这些库碰巧选择了这些库，那么这些警告可能会变得很麻烦。未使用的变量的名称偶尔会与您自己的变量发生冲突。

至于它/它本身 - 老实说，我发现它比下划线更容易打字（作为盲打打字员，我尽可能避免使用下划线 - 太多超出主行），而且我发现它比神秘的下划线更具可读性。

Answer 14

C++ 成员变量前缀的最初想法是存储编译器不知道的附加类型信息。 例如，您可以有一个固定长度字符的字符串，另一个是可变的并以“\0”结尾的字符串。 对于编译器来说，它们都是 char *，但如果您尝试从一个复制到另一个，则会遇到巨大的麻烦。 所以，我突然想到，


char *aszFred = "嗨，我是一个以 null 结尾的字符串";
char *arrWilma = {'O', 'o', 'p', 's'};


其中“asz”表示该变量是“ascii 字符串（以零结尾），而“arr”表示该变量是一个字符数组。

然后神奇的事情就发生了。编译器会对这个语句非常满意：


strcpy(arrWilma, aszFred);


但是，作为一个人，您可以看着它并说“嘿，这些变量实际上并不是同一类型，我不能这样做”。

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

最后，我应该提到两点：

• 明智地使用 C++ 功能可以让编译器知道必须在原始 C 风格变量中编码的信息。 您可以创建只允许有效操作的类。 应尽可能地做到这一点。
• 如果您的代码块太长，以至于您在使用变量之前忘记了变量的类型，那么它们就太长了。 不要使用名称，重新组织。

Answer 15

正如其他人已经说过的，重要的是要口语化（根据您正在编写的代码库调整命名样式和约定）并保持一致。

多年来，我一直致力于使用“this->”的大型代码库。 约定以及对成员变量使用后缀下划线表示法。 多年来，我也参与过较小的项目，其中一些项目没有任何命名成员变量的约定，而其他项目则有不同的成员变量命名约定。 在这些较小的项目中，我一直发现那些缺乏任何约定的项目是最难快速进入和理解的。

我对命名非常严格。 我会为类或变量的名称而苦恼，如果我不能想出一些我认为“好”的东西，我会选择将其命名为一些无意义的名称，并提供一个评论来描述它的真正含义是。 这样，至少这个名字的含义正是我想要表达的意思——不多也不少。 通常，在使用一段时间后，我会发现这个名称实际上应该是什么，并且可以返回并进行适当的修改或重构。

关于 IDE 完成工作这一主题的最后一点——这一切都很好，但在我执行最紧急工作的环境中，IDE 通常不可用。 有时，此时唯一可用的就是“vi”的副本。 另外，我见过许多 IDE 代码补全传播愚蠢行为的情况，例如名称拼写错误。 因此，我宁愿不必依赖 IDE 拐杖。

Answer 16

IMO，这是个人的。 我根本没有添加任何前缀。 无论如何，如果代码是公开的，我认为它应该最好有一些前缀，这样它可以更具可读性。

大公司通常使用自己的所谓“开发人员规则”。
顺便说一句，我看到的最有趣但最聪明的是 DRY KISS（不要重复自己。保持简单，愚蠢）。 :-)

Answer 17

当您有一个大的方法或代码块时，可以很方便地立即知道您是否使用局部变量或成员。 这是为了避免错误并提高清晰度！

Answer 18

其他语言将使用编码约定，只是它们往往有所不同。 例如，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 前缀，因为您的用法以此为前缀。 在编译器强制方法中表示同样的事情。

这并不一定意味着其他方法不好，人们会坚持有效的方法。

Answer 19

其他人尝试强制使用
this->member 每当成为成员时
使用变量

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

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

Answer 20

这些约定就是这样。 大多数商店使用代码约定来简化代码可读性，以便任何人都可以轻松查看一段代码并快速破译公共成员和私有成员等内容。

Answer 21

一些回应侧​​重于重构，而不是命名约定，作为提高可读性的方法。 我不认为其中一个可以替代另一个。

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

我希望大家能够清楚地了解这与成员命名约定的关系：当成员有统一的前缀时，我根本不需要回头看； 我知道在源文件中甚至找不到该声明。

我确信我一开始并不喜欢这些风格。 然而，随着时间的推移，在持续使用它们的环境中工作，我优化了我的思维以利用它们。 我认为，鉴于持续的使用，许多目前对它们感到不舒服的人可能也会更喜欢它们。

Answer 22

我不认为一种语法比另一种语法具有真正的价值。 正如您所提到的，这一切都归结为源文件之间的一致性。

我发现这些规则有趣的唯一一点是当我需要两个名为相同的东西时，例如：

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

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

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

Answer 23

使用成员前缀的主要原因是为了区分同名的成员函数和成员变量。 如果您将 getters 与事物的名称一起使用，这会很有用。

请考虑：

class person
{
public:
    person(const std::string& full_name)
        : full_name_(full_name)
    {}

    const std::string& full_name() const { return full_name_; }
private:
    std::string full_name_;
};

在这种情况下，成员变量不能命名为full_name。 您需要将成员函数重命名为 get_full_name() 或以某种方式修饰成员变量。

Answer 24

在阅读成员函数时，了解谁“拥有”每个变量对于理解变量的含义绝对重要。 在这样的函数中：

void Foo::bar( int apples )
{
    int bananas = apples + grapes;
    melons = grapes * bananas;
    spuds += melons;
}

...很容易看出苹果和香蕉来自哪里，但是葡萄、甜瓜和马铃薯呢？ 我们应该查看全局命名空间吗？ 在类声明中？ 该变量是该对象的成员还是该对象的类的成员？ 如果不知道这些问题的答案，你就无法理解代码。 在较长的函数中，甚至像苹果和香蕉这样的局部变量的声明也可能会在混乱中丢失。

为全局变量、成员变量和静态成员变量（可能分别为 g_、m_ 和 s_）添加一致的标签可以立即澄清情况。

void Foo::bar( int apples )
{
    int bananas = apples + g_grapes;
    m_melons = g_grapes * bananas;
    s_spuds += m_melons;
}

一开始这些可能需要一些时间来适应——但是，编程中有什么不需要适应的呢？ 有一天，连 { 和 } 对你来说都显得很奇怪。 一旦您习惯了它们，它们就会帮助您更快地理解代码。

（使用“this->”代替 m_ 是有道理的，但更加冗长且具有视觉破坏性。我不认为它是标记成员变量的所有使用的良好替代方案。

）上面的论点是将论点扩展到类型。 知道变量的类型“对于理解变量的含义绝对是必要的”，这也可能是正确的。 如果是这样，为什么不为每个变量名称添加一个前缀来标识其类型呢？ 按照这个逻辑，你最终会得到匈牙利表示法。 但许多人发现匈牙利表示法费力、丑陋且无用。

void Foo::bar( int iApples )
{
    int iBananas = iApples + g_fGrapes;
    m_fMelons = g_fGrapes * iBananas;
    s_dSpuds += m_fMelons;
}

匈牙利确实告诉我们一些关于代码的新内容。 我们现在了解到 Foo::bar() 函数中有几个隐式转换。 现在代码的问题是，匈牙利语前缀添加的信息价值相对于视觉成本来说很小。 C++ 类型系统包含许多功能，可帮助类型很好地协同工作或引发编译器警告或错误。 编译器帮助我们处理类型——我们不需要符号来这样做。 我们可以很容易地推断出 Foo::bar() 中的变量可能是数字，如果这就是我们所知道的，那么这足以获得对该函数的一般理解。 因此，了解每个变量的精确类型的价值相对较低。 然而像“s_dSpuds”（甚至只是“dSpuds”）这样的变量的丑陋程度是巨大的。 因此，成本效益分析拒绝匈牙利表示法，而在许多程序员看来，g_、s_和m_的好处压倒了成本。

Answer 25

我不能说它有多广泛，但就我个人而言，我总是（并且一直）在我的成员变量前加上“m”前缀。 例如：

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

这是我使用的唯一前缀形式（我非常反对匈牙利表示法），但多年来它对我很有帮助。 顺便说一句，我通常讨厌在名称（或其他任何地方）中使用下划线，但预处理器宏名称除外，因为它们通常都是大写的。

Answer 26

最近我一直倾向于选择 m_ 前缀而不是根本没有前缀，原因并不在于标记成员变量很重要，而是它避免了歧义，假设你有这样的代码：

void set_foo( int foo) { foo = foo; }

这当然不起作用，只允许一个 foo 。 所以你的选择是：

• this->foo = foo;

  我不喜欢它，因为它会导致参数遮蔽，您不再可以使用 g++ -Wshadow 警告，它的输入时间也比 m_ 长。 当您拥有 int foo; 和 int foo(); 时，您仍然会遇到变量和函数之间的命名冲突。

• foo = foo_; 或 foo = arg_foo;

  已经使用了一段时间，但它使参数列表变得丑陋，文档不应该处理实现中的名称歧义。 这里也存在变量和函数之间的命名冲突。

• m_foo = foo;

  API 文档保持简洁，成员函数和变量之间不会出现歧义，而且输入起来比 this-> 更短。 唯一的缺点是它使 POD 结构变得丑陋，但由于 POD 结构一开始就不会受到名称歧义的影响，因此不需要将其与它们一起使用。 拥有唯一的前缀还可以使一些搜索和替换操作变得更容易。

• foo_ = foo;

  m_ 的大部分优点都适用，但出于美观原因我拒绝它，尾随或前导下划线只会使变量看起来不完整且不平衡。 m_ 看起来更好。 使用 m_ 也更具可扩展性，因为您可以使用 g_ 表示全局变量，使用 s_ 表示静态变量。

PS：在Python或Ruby中看不到m_的原因是这两种语言都强制使用自己的前缀，Ruby使用@作为成员变量，而Python需要>自我。。

Answer 27

我更喜欢后缀下划线，如下所示：

class Foo
{
   private:
      int bar_;

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

Answer 28

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

_Foo

_L

都是保留字，而

_foo

_l

则不是。 还有其他情况不允许在小写字母之前使用下划线。 在我的具体案例中，我发现 _L 恰好被 Visual C++ 2005 保留，并且冲突产生了一些意想不到的结果。

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

以下是有关保留哪些标识符的链接：
在字符串中使用下划线的规则是什么C++ 标识符？

Answer 29

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

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

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

To 。对我来说，这是两全其美的，我有一个可以在需要时使用的前缀，并且只要有可能我就可以将其省略。

当然，明显的反驳是“是的，但是你可以”。一眼就能看出变量是否是类成员”。

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

在实践中，我发现这非常有效。作为一个额外的好处，它允许我轻松地将局部变量提升为类成员（或相反），而无需 。

最重要的是，它是一致的！我不需要做任何特殊的事情或记住任何约定来保持一致性。

---

顺便说一句，您不应该使用前导下划线 。

该标准保留了所有以双下划线或下划线后跟大写字母开头的名称。它还保留了全局命名空间中以单下划线开头的所有名称 /em>

因此，带有前导下划线后跟小写字母的类成员是合法的，但迟早您会对以大写字母开头的标识符执行相同的操作，否则会破坏上述其中之一因此，

如果您想在变量名称中对范围进行编码，则更容易避免使用后缀下划线或 m_ 或仅 m 前缀。

Answer 30

我完全赞成前缀做得好。

我认为（系统）匈牙利表示法是造成前缀的大部分“坏名声”的原因。

这种表示法在强类型语言中基本上没有意义，例如在 C++ 中“lpsz”告诉你你的字符串是一个指向 nul 终止字符串的长指针，当：分段架构是古老的历史，C++ 字符串按照常见约定是指向 nul 终止字符串的指针char 数组，知道“customerName”是一个字符串并不是那么困难！

但是，我确实使用前缀来指定变量的用法（本质上是“Apps Hungarian”，尽管我更喜欢避免使用“匈牙利语”一词，因为它与“系统匈牙利语”有不好且不公平的关联），并且这是一种非常方便的节省时间和减少错误的方法。

我使用：

• m 代表成员
• c 代表常量/只读
• p 代表指针（pp 代表指向指针的指针）
• v 代表易失性
• s 代表静态
• i 代表索引和迭代器
• e 代表事件

我希望创建类型的地方清楚，我使用标准后缀（例如列表、组合框等）。

这使得程序员无论何时看到/使用变量时都知道该变量的用法。 可以说，最重要的情况是指针的“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;
    }
}

您可以在这里看到：

• 成员和参数之间没有混淆
• 索引/迭代器和之间没有混淆items
• 使用一组明确相关的变量（项目列表、指针和索引），避免了通用（模糊）名称（如“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”是否是本地、参数、成员或常量。 我不必将手移到鼠标上，这样我就可以将指针悬停在“数据”上，然后等待工具提示（有时永远不会出现）弹出。 因此，程序员可以更快地阅读和理解代码，因为他们不会浪费时间上下搜索或等待。

（如果您认为自己不浪费时间上下搜索来解决问题，请找到一些您一年前编写但尚未查看的代码
自从。 打开文件并跳到一半而不阅读它。
在你不知道是否可以之前，看看你能从这一点读到多远
某物是成员、参数或本地。 现在跳转到另一个随机
位置...这就是我们单身时整天所做的事情
单步执行别人的代码或尝试了解如何
调用他们的函数）

'm' 前缀还避免了（恕我直言）丑陋且冗长的“this->” 表示法，以及它所保证的不一致（即使你很小心，你通常也会在同一个类中得到“this->data”和“data”的混合，因为没有任何东西强制名称的拼写一致） 。

“this”表示法旨在解决歧义 - 但为什么有人会故意编写可能歧义的代码呢？ 歧义迟早会导致错误。 在某些语言中，“this”不能用于静态成员，因此您必须在编码风格中引入“特殊情况”。 我更喜欢有一个简单的、适用于任何地方的编码规则——明确、明确和一致。

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

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

---

反对的论点

那么，缺点是什么？ 反对前缀的典型论点是：

• “前缀方案是坏/邪恶的”。 我同意“m_lpsz”及其类似内容经过深思熟虑且完全无用。 这就是为什么我建议使用精心设计的符号来支持您的需求，而不是复制不适合您的上下文的内容。 （使用正确的工具来完成工作）。

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

• “前缀让我很困惑”。 就像每个工具一样，直到您学会如何使用它为止。 一旦你的大脑习惯了命名模式，它就会自动过滤掉信息，你就不会介意前缀的存在了。 但你必须扎实地使用这样的方案一两周，然后你才能真正变得“流利”。 就在那时，很多人查看旧代码并开始想知道如果没有良好的前缀方案，他们是如何管理的。

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

• 只需等待变量上弹出工具提示即可找到（部分）信息。 是的。 在支持的情况下，对于某些类型的前缀，当您的代码干净地编译后，等待一段时间后，您可以通读描述并立即找到该前缀将传达的信息。 我觉得前缀是一种更简单、更可靠、更高效的方法。

• “更多的是打字”。 真的吗？ 多一个完整的角色？ 或者是 - 使用 IDE 自动完成工具，通常会减少输入，因为每个前缀字符都会显着缩小搜索空间。 按“e”，您班级中的三个事件会在智能感知中弹出。 按“c”，会列出五个常量。

• “我可以使用 this-> 代替 m”。 嗯，是的，你可以。 但这只是一个更丑陋、更冗长的前缀！ 只是它带来了更大的风险（尤其是在团队中），因为对于编译器来说它是可选的，因此它的使用经常不一致。 另一方面，m 是简短、清晰、明确且非可选的，因此使用它更难犯错误。