浅谈命名规范[纯属强辩]

看到有网友留言，指出了我的命名规范错误，甚感欣慰。确实有部分代码没有按照统一的命名规范书写，实在有碍观瞻，一定注意改正。但是就[一看到上面的代码，第一想法就是c++]这点，因为我似乎也当归结为“严于律人，疏于律己”那类型人，还是要强辩几句（高尔基他们家木匠说过：让板砖来得更猛烈些吧）……

首先，就现实情况来讲，在通常状况下命名规范其实应归属于[规范性建议]那类范畴，而非属于强制范畴。只要不是你所在公司或组织的命名规范，那么命名规范便只是推荐你怎么做，而没有要求要你必须怎么做。

再者，即使是公司的编码规范，也不尽相同，即有那种无所谓随意一页薄纸便打发的、也有那类从互联网上检索来随便什么，而后稍加润色的、也不乏自己洋洋洒洒数万字编码规范的公司存在。谁能强制IBM、微软、SUN都使用一种命名规范呢？

而且，就本质来说，命名规范的产生无外是归结于令别人以约定俗成的方式阅读和修改你开发的程序. 也就是说，是别人期望你如此来写，而非你意愿中的写法。如果别人的意愿发生了转变，那么你的写法也必然会随之发生变化。

进一步讲，命名规范这种事，就从来不是一成不变的，轻易便会被人有意无意间创造出来。


比如还在完善中的C#，它的命名方法，便是一种典型：

C#基本命名方法：

一。常量
带有访问修饰符的常量以骆驼命名法[1]
带有公有访问修饰符，受保护修饰符的常量以帕斯命名法[2]

二。数组
以骆驼命名法[1]。

三。结构
以帕斯卡命名法[2]，用名词或短语作为名称。

四。枚举
以帕斯卡命名法[2]，枚举中的选项也一样。

五，类
以帕斯卡命名方法[2]，确保类的名称是一个名词。

六。成员变量命名。
给公有成员变量，受保护的成员变量或内部成员变量命名应以帕斯卡命名方法，给私有成员变量应使用骆驼命名法[1]并以下划线开头。

七。变量
内联变量（在方法内声明）应以骆驼命名法命名[1]。避免使用单个字符作为变量名称，但循环除外。


常用命名方法：
1，骆驼命名法（camelCasing），第一个字母小写，随后的每个单词的第一个字母大写。混合使用大小写字母来构成变量和函数的名字。
2，帕斯卡命名法（pascalCasing），与骆驼命名法类似。只不过骆驼命名法是首字母小写，而帕斯卡命名法是首字母大写。如：StudentName

下划线命名法，顾名思义就是在命名中加入了下划线的命名规则，用于标示类的私有成员。比如在Java编码中，能有效避免如：
class User
{
String name;
public setName(String name) //冲突
{
this.name = name;
}
}

匈牙利命名法（Charles Simonyi提出，因其出生地得名），变量名＝属性＋类型＋对象描述

这么看的话，本身C#的命名规范，就是一个杂烩。

但我们却也都知道，早期的M$君（^^），事实上是力挺匈牙利命名法的。但是后期，由于匈牙利表示法的复杂性及IDE的广泛使用影响下，除了在控件命名上尚有优势外，就很少再被使用。微软转而以骆驼命名法和帕斯卡命名法外代下划线命名法为主体。

可见，命名规范的最主要意义，还是在于——如何能为最大多数人接受，而不是其他什么。

又比如，虽然同属Java体系，Eclipse的SWT包中同样存在着“反Java规范”的地方。

如在org.eclipse.swt.awt包下，SWT_AWT类就是全文大写，而且还用了下划线，这在以前其他的开源包中是不多见的。但是，却清晰体现了类的作用，应该说，是一种很好的写法，目前正开始流行中……

个人认为，既然命名规范是会不断改变的，那么也就是说，但凡不是为公司写程序或团队开发，完全可以按照自己的方式实现命名规范。（实际上，如果这一过程中你是主导者的话，也可以定义自己的命名规范。）这于人于己都没有太大坏处（注意，是没有“太大”，不是没有。我曾遇到某高人，就因他不希望改变自己加下划线的命名习惯而辞职不干的……结果受他影响，我自己也开始爱加下划线……），说不定，你一不小心创造出一种公认的命名表示法，反而成为X氏命名规范创始人也未可知呢。