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

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

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

我一直在研究我们使用m_作为前缀的项目,在我们仅使用下划线的其他项目上(我个人不喜欢,因为下划线只是不足以说明).

在另一个项目中,我们使用了一个长前缀形式,它也包含变量类型.mul_例如是u nsigned l ong 类型的m ember变量的前缀.

现在让我知道你使用什么样的前缀(请给出一个理由).

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

1> Kevin Conner..：

---

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

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

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

另一个编辑:这样想; 变量的类型和范围是次要信息.它应该可用且易于查找,但不会对您大喊大叫.如果你只是想要读取主要信息 - 代码的意图,那么你会使用像m_或类似的前缀LPCSTR,这会变成噪音.

第三次编辑:无论语言如何,这都适用.

---

这根本不适用于c#.基本上你们中的大多数人都陷入了逻辑谬误:认为"因为它对你们来说不是问题 - 对任何人来说都不是问题".与C#一起使用"m_"og"_" - 不是每个人都是你自己.基本上,共享语法是一种评论工具 - 它并非真正针对独立开发者 - 它的目标是提供其他人可以理解的统一"语言",而不管你的个人怪癖和习惯.

---

因此,如果没有彩色打印机花费1%的时间进行代码审查,那么您必须花费其他99%的难以阅读的代码吗？和你的老板谈谈打印机.

---

虽然这适用于设计为在IDE中解析的语言,例如Java或C#,但它不适用于C++和C(其中某些结构成员每个​​都具有该特定结构*的唯一前缀*).这就是IMNSHO,非常类似于语言,就像大多数语法一样.

---

这是对的,但我们有时会使用打印输出进行代码审查.没有彩色打印机,你就没有突出显示......

---

有一个pro前缀:通过IDE outcompletion快速访问成员变量:输入例如m_并立即获取列表中的所有成员.虽然这不是必不可少的,但它可能会帮助像我一样健忘的人

---

我还没有听到有关简单的"m"和"s"前缀的令人信服的论点.使用前缀,我无需考虑是否需要使用"this"而不管当前的上下文.与语法高亮不同,它也很明显.不同开发人员环境之间颜色和字体样式的含义可能会有很大差异.如果我在你的肩膀上工作,我不想学习你的意思.对不起,但这个答案的论点很弱.我永远不想在开发人员认为"变量的类型和范围"成为次要信息的项目上工作.

2> petr k...：

---

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

这(可以说)不仅使代码更具可读性并且有些"流畅",而且最重要的是鼓励结构良好的类和方法.最后,它归结为一个完全不同于前缀或无前缀dillema的问题.

更新:好吧,品味和偏好改变,不要他们..我现在使用下划线作为成员变量的前缀,因为它已被证明有利于从长远来看识别本地和成员变量.特别是新的团队成员有时很难在两者不容易识别的情况下.

---

请那些让我失望的人澄清一下吗？问题是"你用什么",而不是"什么是最好和唯一的方式".即使它是"什么是最好也是唯一的方式",当然每个人对于作为个人最有利于他的东西都有不同的观点,这不是正确的吗？

---

我完全赞同你在这个_except_上的一件事:使用前缀有助于强调这样一个事实,即更改私有变量将保留其他方法调用的更改.这种强调可以真正帮助心不在焉的开发人员避免创建新的bug.

---

关于改变口味的更新+1!

---

+1更新确认您的首次拍摄是个人偏见,并且由于经验您现在"知道更好".

---

将变量传递给函数Function(int value){m_value = value; 否则你必须为'价值'想出两个不同的名字

3> Paul Tomblin..：

---

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

---

您是否真的想依靠特定IDE的功能来使您的代码可读？

---

名称冲突由"this"解决.字首.

---

使用更好的名称来解决名称冲突...... ;-)

---

不使用下划线或m_的缺陷是当成员变量名和成员函数参数名之间存在名称冲突时.

4> Matt Howells..：

---

仅限下划线.

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

5> fastcall..：

---

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

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

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

6> Jakub Kotrla..：

---

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

因为:

现在IDE输入this.popups intellinsense

在不知道定义命名的情况下,每个人都很明显

BTW前缀变量用字母表示它们的类型已经过时了好的IDE并且让我想起了这篇Joel的文章

---

@compie很容易忘记做很多事情 - 这并不会让它成为不好的做法.

7> Seb Nilsson..：

---

使用C#,我已经从'm _'-前缀移到了下划线,因为'm_'是C++的遗产.

微软官方指南告诉你不使用任何前缀,并在私有成员使用驼峰和对公共成员帕斯卡情况.问题是,这与来自同一来源的另一个指南相冲突,该指南指出您应该使所有代码与.NET中使用的所有语言兼容.例如,VB.NET在外壳之间没有区别.

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

更新:我不认为C#"this." - 前缀有助于"我".在VB中,仍然会看到"Me.age"与"Me.Age"相同.

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_因为它很容易被搜索并且仍然允许变量输入跟随它.同意太多其他框架代码活动使用简单的下划线.