聊聊.net 程序设计——命名规范（上）

转眼工作好几年了，经历了几家公司也参与设计开发了一些项目产品。不敢妄言只能说在技术上有了一些沉淀，想写出来与各位志同的人分享一下。

之前一直在各个技术论坛游走，一直在欣赏其他同仁写的技术文章，不得不说有些让我受益匪浅。怎么说呢三人行必有我师，搞技术的没有人可以样样精通。所以一直也想把我这几年积攒下的东西与各位分享一下。

我先介绍一下，本人这几年一直在搞.net B/S、C/S方向（呵呵，当时就因为是Microsoft的平台所以才选择的）经历了.net framework2.0、3.0、3.5到目前的4.0不得不说微软确实财大气粗推出框架版本这么迅速，框架也越来越完善功能也越来越强大。不得不说这样庞大的一个框架以及后面那样一支庞大的开发团队在短时间内可以不断更新可以无间隙的集成，这样的事情也许只有像微软这样的公司才能够做的到吧！试想这几年所做的国内项目（虽然和Microsoft的framework没法比较）如果可以像framework这样可以快速更新无缝集成，我个人认为除了要有一支技术过硬、高凝聚力、高执行力的团队以外，还要有一套适应所处行业适应所在团队的一套标准。只有有了标准才会有具体的约束具体的方向，对一些事物才会可控。

这样针对上述的标准，我来说说我们搞技术最常用的程序命名规范。也许网上关于命名规范的文章不计其数，我不是在步别人的后尘，我只想谈谈我的体会。

闲话少说，现在开始了。

主要想通过两部分来阐述命名规范的一些相关体会，一部分即《聊聊.net 程序设计——命名规范（上）》，其中将主要讨论如何使用大小写，如何为标识符选择适当的名字，以及如何使用某些特定的术语；另一部分为《聊聊.net 程序设计——命名规范（下）》其中将讨论命名空间、类型、成员、参数、程序集以及资源的命名规范。

那么开始我们上半部分的讨论，如何使用大小写？

众所周知大小写最常用的有两种方法即：

PascalCasing

camelCasing

PascalCasing它把标识符中每个单词的首字母（包括2个单词以上的首字母）大写，如：WebClient；当然其中还有一些特例比如System.IO,其中IO为两个单词的首字母缩写都进行了大写处理，其实这样符合PascalCasing的方法。

camelCasing它把除了第一个单词之外的所有单词的首字母大写，如：propertyName。

一般在实际工作中一般将命名空间、类型及成员的名字采用PascalCasing方法命名，参数采用camelCasing方法命名。

如下：

标识符	大小写	Demo
命名空间	Pascal	System.Net
类型	Pascal	StreamReader
接口	Pascal	IEnumerable
方法	Pascal	ToString
属性	Pascal	Name
事件	Pascal	OnLoad
枚举	Pascal	FileMode
参数	camel	value

 

上述例子阐述了一些开发场景中的命名大小写方式,还有一种即”字段”微软官方推荐使用Pascal大小写命名方法,但我在实际工作中更倾向于按访问修饰符来决定采用哪种大小写命名方式,如:

public、internal、protected采用Pascal

private采用camel

当然这是我的个人习惯而已，在公司内部对于这种习惯也进行了讨论，最终保留了这种方案。

还有一种情况，即上述例如IO的命名。IO是两个单词首字母缩写，IO是微软官方的命名所以大家都熟悉也都接受，但实际工作中个人认为尽量不要采用这种缩写的命名方式，除了你的缩写命名让人可以一目了然（这种情况很少）否则不要采用首字母单词缩写来进行命名，因为这样的命名会让人不熟悉时产生不知所云的影响。

如何为标识符选择适当的名字？

我认为有一下几点：

1、选择易于阅读的名字

一个易于阅读的名字很重要，它可以那你的代码更具可读性在没看代码逻辑前就知道你的方法、属性、事件等的用途。

2、要看重可读性而非简洁性

也许有人认为命名的长度越短越好其实也不尽然，简介的命名也许会让人感觉代码很“干净”但不一定能讲功能逻辑表述清楚，如：GetInt没有GetLength看起来更直观。

3、尽量不要使用下划线、连字符以及其他非字母数字的字符，其实感觉带数字的命名也不是很好，记得当年做GIS时采用ESRI公司的ArcGIS Engine做嵌入式开发时，其中就有用…2的命名方式当时感觉比较混乱不知所以然，当然只是个人感受罢了，仅对于本人自己来说不到万不得已尽量不要采用数字命名。

4、提到命名，不得不提及当年包括现在还有公司采用的匈牙利命名法，即：采用小写形式的数据类型缩写来作为变量名的前缀，这种命名方法在某种程度上确实为我们带来了一些便利如使用得当可以带来更好的可读性，但同时也增加了维护成本，及因维护不当而引起的混淆。因为它需要对各种类型在前期作大量的设计保证不被混淆，这样会大大增加开发维护成本，所以不太推荐使用匈牙利命名方法。

尽量不要使用自己没把握的单词缩写来使命名简介，如：使用ShowWindow要比ShowWin要更易于理解。

尽量使用常用的名称如：item、length、count、value等，因为这种命名有时一个单词已经表述出50%的用途。

最后在C#中有int类型，但大家都知道其实int是System.Int32的别名，还有stirng是String的别名，在我们自己做程序设计时尽量避免使用别名因为别名有可能造成代码混淆，不易于阅读。

以及如何使用某些特定的术语？

避免使用编程语言特用的名字，如：char、float、double、object……..

具体的语言特用 的类型名称在这里就不再列举。

以上是个人对命名规范的理解，也许讨论的比较浅不是很完全，欢迎大家讨论，提出您的意见或者建议。

该文章参考文献——《.net设计规范约定、惯用法与模式》

——小弟不才，欢迎大家转载