您在编码时使用的命名约定是什么?
7 回答
这是来自 MSDN的一般命名约定列表。
然而,我倾向于随波逐流。无论目前有什么标准,通常最容易遵循它们,也许随着时间的推移慢慢改变它。仅仅带着你自己的“标准”想法进入一个项目并尝试实施它们是不切实际的。
使用什么标准并不重要,imo——只是有一些标准,人们知道它们是什么。
我结合使用Hungarian、camel case 和我在项目开始时提出的其他规则。就像现在:
- 方法是大写的(DoThis)
- 变量是驼峰式(thisThing)
- 页面级变量以 _ (_thisWorksEverywhere) 开头
- 区域都是小写(#region 外国属性)
- 属性和对象都是大写的(Object.Property)
- 外部属性以 _ (Object._ForeignGroups) 开头
- 控件在一定程度上是匈牙利语,例如 (txtTextBox) 和 (rptRepeater)。我对什么是习惯并不太严格,因为“水印”可以是 wm 或 wk 或其他,只要它们在我的应用程序中都相互匹配。
...ETC。有些事情是标准的,有些事情取决于解释,但最重要的是整个应用程序的一致性。
可以使用匈牙利符号。我不打扰自己,但我给各种事物(变量、控件等)起合理的名称。
例如,我对控件名称使用匈牙利风格的前缀,例如 txt 代表文本框,btn 代表按钮,pic 代表图片框,lbl 代表标签等。这有助于轻松识别控件是什么。
对于函数名称,我尝试使用合理的解释性名称,但没有任何特定规则。对于变量名,我只是使用解释性名称,但没什么特别的。
为了补充@Aku 的答案,Framework Design Guidelines 的作者已经发布了他们指南的在线摘要版本,重点是命名约定。
一致性是关键。根据您的开发团队的规模,使用一致且记录在案的对流将更容易获取别人的代码并让其他人更容易获取您自己的代码。
伙计们,请不要发布“我喜欢 __field”或“我喜欢 m__field”之类的答案。这是一个非常个人和主观的问题,没有单一的答案。
如果您有任何指导方针,那已经是一个巨大的胜利。开发团队中更糟糕的是缺乏共同的约定。
如果能尝试描述给定指南的一些好处,那就太好了。
例如:
带有下划线的字段前缀可以提高智能感知的自动完成
在保持一致时选择一个。更改名称样式会导致混淆。