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

Question

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

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

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

在另一个项目中,我们使用了一个长前缀形式,它也包含变量类型.mul_例如是u nsigned 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的文章

Answer 7

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

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

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

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

Answer 8

我们使用m_然后稍微修改一下Simonyi表示法,就像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 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 代码看起来很丑陋。