驼峰命名、匈牙利命名、帕斯卡命名规则介绍与比较

来源：网络文章列表 2019-05-20 8

驼峰命名规则:第一个单词以小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母,帕斯卡（pascal）命名方法也叫大驼峰法，相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。帕斯卡（pascal）命名方法常用于类名，函数名，属性，命名空间。匈牙利命名法:变量名=属性+类型+对象描述。

所谓“国有国法，行有行规”，何为行规呢，行规一般是指某一行业的成员共同制定的各种规范和章程,由同行业的人共同遵守。

那么咱程序员这行也有一些约定成俗的规定，今天我跟大家分享的是在编程里变量、函数、类里常用的命名规则。

有一定编程经验的人都知道变量等的命名一般要遵循清晰且有明确的含义，通常使用完整单词或者众所周知的单词缩写构成。

那如何保持清晰、明了呢？

下面我介绍一下当前最为流行的三种规则，驼峰命名、匈牙利命名和帕斯卡命名。

一.驼峰命名：

我们知道如果一个表示符由多个完整单词或者单词缩写构成，如果统一大写或者小写形式并不有利于阅读。

比如productname或者printemployeepaychecks，不利于阅读。

驼峰命名规则：

第一个单词以小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母

myFirstName、myLastName

我们可以看到大写字符好像骆驼的驼峰一样，这也是它名字的由来。采用驼峰命名可以很好提高可读性。

如果再细分，驼峰命名还可以分为小驼峰命名和大驼峰命名，上述代码就是采用小驼峰命名，第一个单词的首字符不会大写，其他单词的首字符都会大写，大驼峰名是所有的单词首字符都会大写，其实也就是下面所要介绍的帕斯卡命名法。

二.帕斯卡命名法:

帕斯卡（pascal）命名方法也叫大驼峰法，相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。帕斯卡（pascal）命名方法常用于类名，函数名，属性，命名空间。

例如：

DataBaseUser
ProductName

三.匈牙利命名法：

此命名法据说是一位在微软工作的匈牙利程序员所发明，所以取名为匈牙利命名法。借着微软的产品和文档的东风，此命名法逐渐在世界范围流行开来。

此命名法对标识符进行了更为精细的划分，传达给阅读者的信息也会更多。

基本原则是：变量名=属性+类型+对象描述。

匈牙利命名法关键是：表示属性和类型的部分采用小写，功能描述部分首字母大写的一个单词或多个单词组合。

bShow      //布尔型变量
g_bShow    //全局布尔类型变量
aPrice[30] // 数组

匈牙利命名常见的一些规则

前　缀        类　　型
a             数组 (Array)  
b             布尔值 (Boolean)  
by            字节 (Byte)  
c             有符号字符 (Char)  
cb            无符号字符 (Char Byte，没有多少人用)  
cr            颜色参考值 (ColorRef)  
cx,cy         坐标差（长度 ShortInt）  
dw            Double Word  
fn            函数  
h             Handle（句柄）  
i             整型  
l             长整型 (Long Int)  
lp            Long Pointer  
m_            类的成员  
n             短整型 (Short Int)  
np            Near Pointer  
p             Pointer  
s             字符串型  
sz            以null做结尾的字符串型 (String with Zero End)  
w             Word

三：匈牙利命名法优缺点

优点：（1）匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对 First，Min，Last，Max 和 Lim 的准确区分在实际中是尤其有帮助的。

（2）匈牙利约定可以使人对编译程序无法检查的抽象数据类型进行检查：cpaReformat[i]很可能是错误的，因为cpaReformat 不是数组，而 apaReformat[i]则可能是正确的，因为 apaReformat[i]是数组。

（3）匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如，在 Windows 环境下编程时，需要你放弃许多类型，这极大地限制了编译程序进行严格类型检查的能力。而建立约定则可以对环境的这一弱点作出补偿，匈牙利约定还可以使名称更简洁，可以用 CMedals 而不用 TotalMedals 来代表奖牌的数量，使用 pNewScore，而不是用 NewScorePtr 命名一个新分数指针。

缺点：（1）一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言中整型、长整型、浮点数和字符串为基础来建立基本类型。

（2）匈牙利约定基本类型事实上是没有什么价值的，因为它使得程序员陷入对类型进行人工检查的困扰之中，而不是让编译程序对类型进行更加快速而又准确的检查。这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如，说明某一变量是整型的，把它改为长整型的时，不得不改动这一变量的名称。

（3）匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序员用hwnd 来命名对窗口的操作时，往往忽视了他所指的到底是哪种窗口、对话框、菜单还是帮助区的屏幕？显然用 hwndmenu 要比 hwnd 清楚得多。以变量的意义为代价来获得对其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义和精确的类型。