毫无疑问,理解代码必须给成员变量一个前缀,这样才能很容易地将它们与"普通"变量区分开来.
但是你使用什么样的前缀?
我一直在研究我们使用m_作为前缀的项目,在我们仅使用下划线的其他项目上(我个人不喜欢,因为下划线只是不足以说明).
在另一个项目中,我们使用了一个长前缀形式,它也包含变量类型.mul_例如是u nsigned l ong 类型的m ember变量的前缀.
现在让我知道你使用什么样的前缀(请给出一个理由).
编辑:大多数人似乎没有成员变量的特殊前缀代码!这取决于语言吗?根据我的经验,C++代码倾向于使用下划线或m_作为成员变量的前缀.其他语言怎么样?
毫无疑问,理解代码必须给成员变量一个前缀,这样才能很容易地将它们与"普通"变量区分开来.
我对此声称提出质疑.如果你有一个不错的语法突出显示,这一点也不是必需的.一个好的IDE可以让你用可读的英语编写你的代码,并可以通过其他方式向你展示符号的类型和范围.当插入点位于其中一个符号上时,Eclipse通过突出显示符号的声明和使用来做得很好.
编辑,谢谢苗条:像Eclipse这样好的语法荧光笔也可以让你使用粗体或斜体文字,或者完全改变字体.例如,我喜欢静态的斜体.
另一个编辑:这样想; 变量的类型和范围是次要信息.它应该可用且易于查找,但不会对您大喊大叫.如果你只是想要读取主要信息 - 代码的意图,那么你会使用像m_
或类似的前缀LPCSTR
,这会变成噪音.
第三次编辑:无论语言如何,这都适用.
我根本不使用任何前缀.如果我遇到将局部变量或方法参数与类成员混合的危险,那么方法或类太长并且可以从拆分中受益.
这(可以说)不仅使代码更具可读性并且有些"流畅",而且最重要的是鼓励结构良好的类和方法.最后,它归结为一个完全不同于前缀或无前缀dillema的问题.
更新:好吧,品味和偏好改变,不要他们..我现在使用下划线作为成员变量的前缀,因为它已被证明有利于从长远来看识别本地和成员变量.特别是新的团队成员有时很难在两者不容易识别的情况下.
没有.我曾经使用下划线,但是在一个其他人不喜欢它的项目中被讨论过,并且没有错过它.一个体面的IDE或体面的记忆会告诉你什么是成员变量,什么不是.我们项目的开发人员之一坚持要把"这个".在每个成员变量面前,当我们处理名义上"他的"代码区域时,我们会幽默他.
仅限下划线.
就我而言,我使用它是因为这就是编码标准文件在我的工作场所所说的.但是,我不能在变量的开头看到添加m_或一些可怕的匈牙利事物的意义.极简主义'仅限下划线'使其可读.
保持一致性比任何事情都重要,所以选择你和你的队友可以达成一致的东西并坚持下去.如果你编写的语言有一个约定,你应该试着坚持下去.没有什么比遵循前缀规则不一致的代码库更令人困惑.
对于c ++,除了_有时前缀为编译器关键字这一事实外,还有另一个理由更喜欢m_ over _.m代表成员变量.这也使您能够消除局部变量和其他变量类之间的歧义,s_表示静态,g_表示全局变量(但当然不使用全局变量).
至于IDE将始终关注您的评论,IDE是否真的是您查看代码的唯一方式?您的diff工具是否具有与IDE相同的语法高亮质量级别?你的源代码管理修订历史工具怎么样?你甚至从未将源文件存入命令行吗?现代IDE是非常棒的效率工具,但无论您正在阅读它的上下文,代码都应该易于阅读.
我更喜欢使用this
关键字.这意味着this.data
或this->data
代替一些依赖于社区的命名.
因为:
现在IDE输入this.
popups intellinsense
在不知道定义命名的情况下,每个人都很明显
BTW前缀变量用字母表示它们的类型已经过时了好的IDE并且让我想起了这篇Joel的文章
使用C#,我已经从'm _'-前缀移到了下划线,因为'm_'是C++的遗产.
微软官方指南告诉你不使用任何前缀,并在私有成员使用驼峰和对公共成员帕斯卡情况.问题是,这与来自同一来源的另一个指南相冲突,该指南指出您应该使所有代码与.NET中使用的所有语言兼容.例如,VB.NET在外壳之间没有区别.
所以对我来说只是一个下划线.这也使得通过IntelliSense轻松访问,只调用公共成员的外部代码不必看到视觉上凌乱的下划线.
更新:我不认为C#"this." - 前缀有助于"我".在VB中,仍然会看到"Me.age"与"Me.Age"相同.
我们使用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_因为它很容易被搜索并且仍然允许变量输入跟随它.同意太多其他框架代码活动使用简单的下划线.