Question

毫无疑问，理解代码必须给成员变量一个前缀，这样才能很容易地将它们与“普通”变量区分开来。

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

我一直在处理我们使用 m _ 作为前缀的项目，在我们仅使用下划线的其他项目上（我个人不喜欢，因为下划线只是不足以说明）。

在另一个项目中，我们使用了一个长前缀形式，它也包含了变量类型。 mul _ 例如 m 类型 u 符号 l ong的 m ember变量的前缀。

现在让我知道您使用的是什么类型的前缀（并请说明理由）。

编辑：大多数人似乎没有成员变量的特殊前缀代码！这取决于语言吗？根据我的经验， C ++代码倾向于使用下划线或 m _ 作为成员变量的前缀。其他语言怎么样？

Answer 1

毫无疑问，理解代码必须给成员变量一个前缀，这样才能很容易地将它们与“普通”变量区分开来。

我对此声明提出质疑。如果你有一个不错的语法突出显示，这一点也不是必需的。一个好的IDE可以让你用可读的英语编写你的代码，并可以通过其他方式向你展示符号的类型和范围。当插入点位于其中一个上时，Eclipse通过突出显示符号的声明和使用来做得很好。

编辑，谢谢苗条：像Eclipse这样好的语法荧光笔也可以让你使用粗体或斜体文字，或者完全改变字体。例如，我喜欢静态的斜体。

另一个编辑：这样想;变量的类型和范围是次要信息。它应该可用且易于查找，但不会对您大喊大叫。如果您使用m_之类的前缀或类似LPCSTR的类型，当您只想阅读主要信息 - 代码的意图时，这就会变成噪音。

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

Answer 2

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

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

更新：好吧，味道和偏好改变，不是它们..我现在使用下划线作为成员变量的前缀，因为它已被证明有利于长期识别本地和成员变量。特别是新的团队成员有时很难在两者不容易辨认的情况下。

Answer 3

无。我曾经使用下划线，但是在一个其他人不喜欢它的项目中被讨论过，并且没有错过它。一个体面的IDE或体面的记忆会告诉你什么是成员变量，什么不是。我们项目的开发人员之一坚持要把“这个”。在每个成员变量面前，当我们处理名义上“他的”代码区域时，我们会幽默他。

Answer 4

仅限下划线。

就我而言，我使用它是因为这就是编码标准文件在我的工作场所所说的内容。但是，我不能在变量的开头看到添加m_或一些可怕的匈牙利事物的意义。极简主义'仅限下划线'使其可读。

Answer 5

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

对于c ++，除了_有时前缀为编译器关键字这一事实之外，还有另一个理由更喜欢m_ over _。 m代表成员变量。这也使您能够消除本地和其他变量类之间的歧义，s_表示静态，g_表示全局（但当然不使用全局变量）。

对于IDE将始终关注您的评论，IDE是否真的是您查看代码的唯一方式？您的diff工具是否具有与IDE相同的语法高亮质量级别？你的源代码管理修订历史工具怎么样？你甚至从未将源文件存入命令行吗？现代IDE是非常棒的效率工具，但无论您正在阅读它的上下文，代码都应该易于阅读。

Answer 6

我更喜欢使用this关键字。这意味着this.data或this->data，而不是某些与社区相关的命名。

由于：

现在IDE输入this. popups intellinsense
在不知道定义命名的情况下对每个人都很明显

BTW前缀变量用字母表示它们的类型已经过时了好的IDE并让我想起了这个Joel's article

Answer 7

使用C＃，我已经从'm _'-前缀转移到只是一个下划线，因为'm_'是来自C ++的遗产。

Microsoft官方指南告诉您不要使用任何前缀，在私人成员上使用驼峰式内容，在公共成员上使用 pascal-case 。问题是，这与来自同一来源的另一个指南相冲突，该指南指出您应该使所有代码与.NET中使用的所有语言兼容。例如，VB.NET在外壳之间没有区别。

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

更新：我不认为 C＃“这个。” - 前缀有助于“我”。在VB中，仍然会看到“Me.age”与“Me.Age”相同。

Answer 8

我们使用m_然后稍微修改一下Simonyi表示法，就像Rob在之前的回复中说的那样。因此，前缀似乎很有用，并且m_不会过于干扰并且很容易被搜索。

为什么表示符号？为什么不遵循（针对.NET）依赖于名称大小的Microsoft符号建议？

后面的问题：正如所指出的，VB.NET对套管无动于衷。数据库和（特别是）DBA也是如此。当我必须保持直接的customerID和CustomerID（比方说，C＃）时，它会让我的大脑受伤。套管是一种符号形式，但不是一种非常有效的形式。

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

在不使用IDE的情况下增加人们对代码的理解。在代码审查中 - 我最初仍然觉得最容易在纸上做。
曾经写过T-SQL或其他RDBMS存储过程吗？在数据库列名上使用前缀表示法非常有帮助，特别是对于那些喜欢使用文本编辑器来处理这类内容的人。

也许简而言之，作为符号形式的前缀很有用，因为仍然存在智能IDE不可用的开发环境。将IDE（一种软件工具）视为允许我们使用一些快捷方式（如智能感知打字），但不包括整个开发环境。

IDE是集成开发环境，与汽车是交通网络的方式相同：只是大型系统的一部分。我不想遵循像停留在标记道路上的“汽车”惯例，有时，它更快地走过空地。依靠IDE来跟踪变量输入就像是需要汽车的GPS来穿过空置的地段。最好是以便携式形式获得知识（尽管可能是“m_intCustomerID”），而不是为了每次小的变化而跑回汽车。

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

Answer 9

我用“m”和成员变量（在函数中）用'p'作为前缀。所以代码看起来像：

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

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

Answer 10

这实际上取决于语言。我是一个C ++人，用下划线为所有内容添加前缀有点棘手。在某些情况下，语言会保留以下划线开头的内容（取决于范围）。还有一个特殊的处理方式，双下划线或下划线跟随大写字母。所以我说只是避免那些混乱，只需选择其他一些前缀。 '我'是好的IMO。 'm_'有点多，但也不是很糟糕。真的是品味问题。

但请注意那些_leadingUnderscores。你会惊讶地发现有多少编译器和库内部命名，如果你不是非常小心的话，肯定会有意外和混乱的空间。说不。

Answer 11

这取决于我使用的是哪个框架！如果我正在编写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 12

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

Answer 13

`_`代替`this.`

我也使用_代替this.因为更短（ 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 14

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

Answer 15

单个 _ 仅用作可视指示符。（C＃）

有助于使用intellisense对成员进行分组。
在阅读代码时更容易发现成员变量。
更难用本地定义隐藏成员变量。

Answer 16

另一个技巧是命名约定：

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

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

a Something：代表一个对象。
一些 ManyThings：对象列表。
AState或 SomeThing：for boolean state。

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

Answer 17

由于VB.NET不区分大小写，因此我使用下划线和驼峰大小写为我的成员变量加上名称的其余部分。我将属性名称大写。

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 18

我很奇怪，我在成员变量前面添加了类名称的首字母（这是驼峰式的）。

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

大多数德尔福人只使用F。

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

Answer 19

这取决于你在做什么语言。

在C＃中，您可以使用“this”前缀引用任何成员，例如'this.val'，表示不需要前缀。 VB与'Me'具有相似的功能。

在有指示成员访问的内置表示法的语言中，我没有看到使用前缀的重点。在其他语言中，我认为使用该语言的普遍接受的约定是有意义的。

请注意，使用内置表示法的一个好处是，您还可以在访问类的属性和方法时使用它，而不会影响您的命名约定（这在访问非私有成员时尤其重要）。使用任何类型的指标的主要原因是作为一个标志，你在课堂上可能产生副作用，所以在使用其他成员时，不管它们是字段/属性/方法/等，都是个好主意。

Answer 20

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

IDE现在非常好用，通过语法着色，鼠标悬停工具提示以及轻松导航到其定义，很容易找到有关变量的信息。

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

我多年没有使用前缀，但我曾经是“这个”。前缀怪物，但我已经离开了，除非绝对必要（谢谢，Resharper）。

Answer 21

我喜欢m_但是只要在代码库中使用约定我就会很酷。

Answer 22

我在这里使用驼峰案例和许多下划线。我使用下划线因为我使用C＃而且我习惯于在构造函数中避免使用'this'关键字。我使用了方法范围的变体，因此下划线提醒我当时正在使用的范围。否则，只要您没有尝试添加代码中已经明显的不必要信息，我认为这并不重要。

Answer 23

我曾经习惯在C ++中使用m_前缀，但在C＃中，我更喜欢使用字段的camel case和其属性的pascal case。

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

Answer 24

在Java中，一个常见的约定是使用“my”和UseCamelCaseForTheRestOfTheVariableName为成员变量作序。

Answer 25

对于我自己的项目，我使用_作为后缀（如上面提到的Martin York，_作为前缀是编译器实现的C / C ++标准的reserver）和我在处理Symbian projects时。

Answer 26

如果确实需要为成员变量添加前缀，我肯定更喜欢m_只是一个下划线。我发现它自己的下划线降低了可读性，并且可能与C ++保留字混淆。

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

Answer 27

没有前缀。而且，对于纯函数/堆栈没有变量名。但如果我真的必须使用副作用，如果我想输出任何东西，那么我使用p->其中p是传递给我的函数的参数的外部指针。

我认为使用前缀/前缀会变得愚蠢。

__EXTERN_GLOBAL_hungariannotationvariabletypeVendorName-my_member_prefix-Category-VariableName

考虑mul示例，我的成员变量是一个无符号长整数，表示乘法指令的操作码可能是mulmul。

Answer 28

我使用@。

：D j / k - 但是如果有的话取决于语言。如果它有getter / setter，我通常会在私有成员变量前放一个_，而getter / setter将没有_的同名。否则，我通常不使用任何。

Answer 29

Symbian使用'i'作为成员的前缀，使用'a'作为参数。

Answer 30

我只使用_ 后缀（前缀_在c / c ++中保留，正如上面提到的那样）。我喜欢它主要是因为我讨厌像'aCircle'这样的参数名称，除非绝对必要，否则我不喜欢写出这个.circle。（我只对公共访问成员变量执行此操作，'对于这些变量，我不使用下划线后缀）。

Answer 31

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

Answer 32

如果没有必要，则为无，否则为单下划线。适用于python。

Answer 33

你的mul_例子正朝着Charles Simonyi的Apps匈牙利语表示法。

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

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

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

33 个答案:

`_`代替`this.`

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

33 个答案:

_代替this.

`_`代替`this.`