成员变量使用什么样的前缀？

Question

毫无疑问，对于理解代码来说，给成员变量一个前缀至关重要，以便可以轻松地将它们与“普通”变量区分开来。

但是你使用什么样的前缀呢？

我一直在使用 m_ 作为前缀的项目，在其他项目中我们仅使用下划线（我个人不喜欢，因为仅使用下划线不够说明性）。

在另一个项目中，我们使用了长前缀形式，其中还包括变量类型。 例如，mul_ 是 unsigned long 类型的 member 变量的前缀。

现在让我知道您使用哪种前缀（并请给出原因）。

编辑：你们中的大多数人似乎在编码时没有为成员变量添加特殊前缀！ 这取决于语言吗？ 根据我的经验，C++ 代码倾向于使用下划线或m_ 作为成员变量的前缀。 其他语言呢？

Answer 1

毫无疑问，对于理解代码来说，为成员变量赋予前缀至关重要，以便可以轻松地将它们与“普通”变量区分开来。

我对这种说法提出异议。 如果你的语法高亮还算不错，那么这根本就不是必要的。 一个好的 IDE 可以让您用可读的英语编写代码，并可以通过其他方式向您显示符号的类型和范围。 当插入点位于其中一个符号上时，Eclipse 会突出显示符号的声明和使用，从而做得很好。

编辑，谢谢 slim：像 Eclipse 这样的良好语法荧光笔还可以让您使用粗体或斜体文本，或者完全更改字体。 例如，我喜欢用斜体来表示静态的东西。

另一个编辑：这样想； 变量的类型和范围是次要信息。 它应该是可用的并且很容易找到，但不会对你大喊大叫。 如果您使用像 m_ 这样的前缀或像 LPCSTR 这样的类型，当您只想读取主要信息（代码的意图）时，它们就会变成噪音。

第三次编辑：无论语言如何，这都适用。

Answer 2

我根本不使用任何前缀。 如果我遇到将局部变量或方法参数与类成员混淆的危险，那么方法或类就会太长，并且可以从拆分中受益。

这（可以说）不仅使代码更具可读性并且有些“流畅”，而且最重要的是鼓励结构良好的类和方法。 最终，它归结为一个与前缀或无前缀困境完全不同的问题。

更新：嗯，品味和偏好会改变，不是吗。我现在使用下划线作为成员变量的前缀，因为从长远来看，它已被证明有利于识别本地变量和成员变量。 尤其是新团队成员有时会因为两人不容易被认出而感到困难。

Answer 3

没有任何。 我曾经使用过下划线，但是在一个其他人不喜欢它的项目中被劝说放弃了，并且没有错过它。 一个好的 IDE 或一个好的记忆力会告诉你什么是成员变量，什么不是。 我们项目的一位开发人员坚持要加上“这个”。 在每个成员变量前面，当我们处理名义上“他的”代码区域时，我们会迁就他。

Answer 4

仅下划线。

就我而言，我使用它是因为这就是我工作场所的编码标准文档的规定。 但是，我看不出在变量开头添加 m_ 或一些可怕的匈牙利语的意义。 极简主义的“仅下划线”使其具有可读性。

Answer 5

保持一致比任何事情都更重要，所以选择你和你的队友可以同意的事情并坚持下去。 如果您编码所用的语言有约定，您应该尝试遵守它。 没有什么比遵循不一致的前缀规则的代码库更令人困惑的了。

对于 C++，除了 _ 有时作为编译器关键字前缀之外，还有另一个原因更喜欢 m_ 而不是 _。 m代表成员变量。 这还使您能够消除局部变量和其他变量类别之间的歧义，s_ 表示静态变量，g_ 表示全局变量（但当然不要使用全局变量）。

至于 IDE 将永远照顾您的评论，IDE 真的是您查看代码的唯一方式吗？ 您的 diff 工具是否具有与 IDE 相同的语法高亮质量水平？ 您的源代码管理修订历史记录工具怎么样？ 您甚至从未将源文件cat到命令行吗？ 现代 IDE 是出色的效率工具，但无论您在什么上下文中阅读代码，都应该易于阅读。

Answer 6

我更喜欢使用 this 关键字。
这意味着 this.data 或 this->data 而不是一些依赖于社区的命名。

因为：

• 在当今的 IDE 中，输入 this. 弹出 intellinsense
• 对于每个人来说都是显而易见的，而不知道定义的命名

BTW 用字母前缀变量来表示其类型对于好的 IDE 来说已经过时了，并让我想起了这个 乔尔的文章

Answer 7

我们使用 m_，然后稍微修改一下西蒙尼表示法，就像 Rob 在之前的回复中所说的那样。 因此，前缀似乎很有用，而且 m_ 不太具有侵入性并且很容易搜索。

为什么要使用符号呢？ 为什么不遵循（对于 .NET）依赖于名称大小写的 Microsoft 表示法建议呢？

首先是后一个问题：正如所指出的，VB.NET 对大小写无关。 数据库和（尤其是）DBA 也是如此。 当我必须直接保存 customerID 和 CustomerID（例如，C# 中）时，我的大脑很受伤。 所以大小写是一种表示法，但不是一种非常有效的表示法。

前缀表示法具有以下几个方面的价值：

1. 无需使用 IDE 即可提高人们对代码的理解。 就像代码审查一样——我仍然发现最初在纸上进行是最容易的。
2. 曾经编写过 T-SQL 或其他 RDBMS 存储过程吗？ 在数据库列名上使用前缀表示法确实很有帮助，特别是对于我们这些喜欢使用文本编辑器进行此类操作的人来说。

也许简而言之，前缀作为一种表示法很有用，因为仍然存在无法使用智能 IDE 的开发环境。 将 IDE（一种软件工具）视为允许我们使用一些快捷方式（例如智能感知输入），但不包含整个开发环境。

IDE 是一种集成开发环境，就像汽车是交通网络一样：只是更大系统的一部分。 我不想遵循“汽车”惯例，比如留在有标记的道路上，有时，步行穿过空地会更快。 依靠 IDE 来跟踪变量类型就像需要汽车的 GPS 来穿过空地一样。 当然，以可移植的形式掌握这些知识（尽管可能会很尴尬，因为“m_intCustomerID”可能很尴尬）比每次微小的改变都跑回车上要好。

也就是说，m_ 约定或“this”约定都是可读的。 我们喜欢 m_，因为它很容易搜索，并且仍然允许变量类型跟随它。 同意太多其他框架代码活动使用了简单的下划线。

Answer 8

使用 C#，我已将“m_”前缀改为仅一个下划线，因为“m_”是继承自 C++。

官方的 Microsoft 指南告诉您不要使用任何前缀，并在私有成员上使用驼峰命名法，在公共成员上使用帕斯卡命名法。 问题在于，这与同一来源的另一条准则相冲突，该准则规定您应该使所有代码与 .NET 中使用的所有语言兼容。 例如，VB.NET 不区分大小写。

所以对我来说只是一个下划线。 这也使得通过 IntelliSense 访问变得容易，并且仅调用公共成员的外部代码不必看到视觉上混乱的下划线。

更新：我不认为C#“this.”前缀对“Me”有帮助。 在 VB 中，“Me.age”仍然与“Me.Age”相同。

Answer 9

这取决于我使用哪个框架！ 如果我正在编写 MFC 代码，那么我会使用 m_ 和匈牙利表示法。 对于其他东西（通常是 STL/Boost），我会为所有成员变量添加下划线后缀，并且我不关心匈牙利表示法。

MFC 类

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STL 类

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

现在这可能看起来有点奇怪 - 两种不同的样式 - 但它对我有用，并且编写了很多不使用相同样式的 MFC 代码MFC本身的风格只是看起来很丑。

Answer 10

这实际上取决于语言。
我是一名 C++ 人员，在所有内容前添加下划线前缀有点棘手。 该语言保留以下划线开头的内容，以便在某些情况下实现（取决于范围）。 对于双下划线或下划线后跟大写字母也有特殊处理。 所以我说，只要避免这种混乱，只需选择其他一些前缀即可。 在我看来，“m”是可以的。 “m_”有点多，但也不可怕。 确实是品味问题。

但要注意那些 _leadingUnderscores。 您会惊讶地发现有多少编译器和库内部是这样命名的，如果您不非常小心，肯定有可能发生意外和混淆。 拒绝吧。

Answer 11

我在成员变量前加上“m”前缀，在参数（函数中）前加上“p”前缀。 所以代码看起来像：

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

我发现这可以快速告诉您任何变量的基本范围 - 如果没有前缀，那么它是本地变量。 此外，在读取函数时，您不需要考虑传入的内容以及局部变量。

Answer 12

大多数时候，我使用Python。 Python 要求您使用 self.foo 才能访问当前类实例的属性 foo。 这样，您所处理的实例的局部变量、参数和属性混淆的问题就解决了。
一般来说，我喜欢这种方法，尽管我不喜欢被迫这样做。 因此，我的理想方法是不这样做，而是在 this 或 self 上使用某种形式的属性访问来获取成员变量。 这样，我就不必用元数据来混淆名称。

Answer 13

我很奇怪，我在成员变量前加上类名（驼峰式）的首字母缩写。

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

大多数Delphi人只使用F。

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

Answer 14

如果语言支持 this 或 Me 关键字，则不使用前缀，而是使用所述关键字。

Answer 15

另一个技巧是命名约定：

所有成员变量都像往常一样命名，没有任何前缀（或“this.”，在项目中通常这样做），

但它们很容易与局部变量区分开来因为在我的项目中，这些局部变量总是命名为：

• aSomething：代表一个对象。
• someManyThings：对象列表。
• isAState 或 hasSomeThing：用于布尔状态。

任何不以“a”、“some”或“is/has”开头的变量都是成员变量。

Answer 16

由于 VB.NET 不区分大小写，因此我在成员变量前添加下划线前缀，并在名称的其余部分中使用驼峰式大小写。 我将属性名称大写。

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 17

我和那些不使用前缀的人在一起。

现在的 IDE 非常好，从语法着色、鼠标悬停工具提示和轻松导航到其定义，可以轻松一目了然地找到有关变量的信息。

这是您可以从变量和命名约定的上下文中获得的内容（例如局部变量和私有字段的小驼峰命名法，属性和方法的大驼峰命名法等）以及布尔值的“hasXXXX”和“isXX”等内容。

我已经很多年没有使用前缀了，但我确实曾经是“this”。 前缀怪物，但除非绝对必要，否则我已经放弃了（谢谢，Resharper）。

Answer 18

单个 _ 仅用作视觉指示器。 (C#)

• 有助于通过智能感知对成员进行分组。
• 阅读代码时更容易发现成员变量。
• 更难隐藏具有局部定义的成员变量。

Answer 19

_ 而不是 this.

我也使用 _ 而不是 this. 因为只是更短 strong>（少 4 个字符），它是成员变量的一个很好的指示符。 此外，使用这个前缀可以避免命名冲突。 示例：

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

与此相比：

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

我发现第一个示例更短、更清晰。

Answer 20

这有点取决于您使用的语言。

在 C# 中，您可以使用“this”前缀引用任何成员，例如“this.val”，这意味着不需要前缀。 VB 具有与“Me”类似的功能。

在有用于指示成员访问的内置符号的语言中，我不认为使用前缀有什么意义。 在其他语言中，我认为使用该语言普遍接受的约定是有意义的。

请注意，使用内置表示法的好处之一是，您还可以在访问类上的属性和方法时使用它，而不会影响这些属性和方法的命名约定（这在访问非私有成员时尤其重要）。 使用任何类型的指示器的主要原因是作为一个标志，表明您可能在类中造成副作用，因此在使用其他成员时最好使用它，无论它们是否是字段/属性/方法/等。

Answer 21

我像这里的许多人一样使用驼峰式大小写和下划线。 我使用下划线是因为我使用 C# 并且已经习惯在构造函数中避免使用“this”关键字。 我使用驼峰式大小写方法范围的变体，因此下划线提醒我当时正在使用的范围。 否则，只要您不尝试添加代码中已经明显的不必要的信息，我认为这并不重要。

Answer 22

我曾经在 C++ 中使用 m_ perfix，但在 C# 中我更喜欢仅对字段使用驼峰式大小写，对其属性使用帕斯卡大小写。

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Answer 23

我喜欢 m_ 但只要在代码库中使用约定，我就很乐意。

Answer 24

您的 mul_ 示例正朝着 Charles Simonyi 的 Apps Hungarian notation 方向发展。

我更喜欢保持简单，这就是为什么我喜欢使用 m_ 作为前缀。

这样做可以更容易地了解您必须去哪里查看原始声明。

Answer 25

我倾向于在 C++ 中使用 m_，但不介意在 Java 或 C# 中将其保留。 这取决于编码标准。 对于混合有下划线和 m_ 的遗留代码，我会将代码重构为一个标准（给定合理的代码大小）

Answer 26

我用 @。

:D j/k ——但是这确实取决于语言。 如果它有 getter/setter，我通常会在私有成员变量前面放一个 _，并且 getter/setter 将具有相同的名称，但不带 _。 否则，我通常不会使用任何东西。

Answer 27

对于我自己的项目，我使用 _ 作为后缀（正如 Martin York 上面指出的那样，_ 作为前缀是编译器实现的 C/C++ 标准的保留符），而在处理 Symbian 项目。

Answer 28

在 Java 中，一种常见的约定是在成员变量前加上“my”并使用 CamelCaseForTheRestOfTheVariableName。

Answer 29

如果没有必要就没有，否则单下划线。 适用于Python。

Answer 30

如果确实需要为成员变量添加前缀，我肯定会更喜欢 m_ 而不是仅使用下划线。 我发现下划线本身会降低可读性，并且可能与 C++ 保留字混淆。

但是，我确实怀疑成员变量是否需要任何特殊符号。 即使忽略 IDE 帮助，也不清楚为什么本地变量和成员变量之间会出现混淆。