编程命名规范

一、简介

无以规矩，不成方圆。
符合规范的统一命名是程序编写的基本规矩之一。很多时候我们不愿意接手别人的代码，原因之一就是代码命名很乱；我们自己写代码时经常写到后面忘了前面，也有可能是我们没有养成规范的命名习惯。当写代码成为一种艺术的美时，这种美的最直接的体现就是其中变量函数等命名的规范性。

首先总结一下命名的基本原则，也就是“道”的层次。

二、分类

目前业界共有四种常见的命名法则：驼峰命名法、匈牙利命名法、帕斯卡命名法和下划线命名法，其中前三种是较为流行的命名法。

1、匈牙利命名法

匈牙利命名法是早期的规范，由微软的一个匈牙利人发明的，是 IDE 还十分智障的年代的产物。那个年代，当代码量很多的时候，想要确定一个变量的类型是很麻烦的，不像现在 IDE 都会给提示，所以才产生了这样一个命名规范，估计现在已经没啥人用了吧……一个十分系统却又琐碎的命名规范。

该命名规范，要求前缀字母用变量类型的缩写，其余部分用变量的英文或英文的缩写，单词第一个字母大写。

例子：

int iMyAge;        #  "i": int
char cMyName[10];  #  "c": char
float fManHeight;  #  "f": float

其他
前缀类型还有：

a      数组（Array）
b      布尔值（Boolean）
by     字节（Byte）
c      有符号字符（Char）
cb     无符号字符（Char Byte，并没有神马人用的）
cr     颜色参考值（Color Ref）
cx,cy  坐标差（长度 Short Int）
dw     双字（Double Word）
fn     函数（Function）
h      Handle（句柄）
i      整形（Int）
l      长整型（Long Int）
lp     长指针（Long Pointer）
m_     类成员（Class Member）
n      短整型（Short Int）
np     近程指针（Near Pointer）
p      指针（Pointer）
s      字符串（String）
sz     以 Null 做结尾的字符串型（String with Zero End）
w      字（Word）

还有其他更多的前缀是根据微软自己的 MFC/句柄/控件/结构等东西定义的，就不过多描述了。

驼峰式命名法

骆峰式命名法（Camel-Case）是电脑程式编写时的一套命名规则（惯例）。

骆峰式命名法就是当变量名或函式名是由一个或多个单字连结在一起，而构成的唯一识别字时，第一个单词以小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母!

小驼峰法

变量一般用小驼峰法标识。驼峰法的意思是：除第一个单词之外，其他单词首字母大写。譬如int studentCount=0；

变量myStudentCount第一个单词是全部小写，后面的单词首字母大写。

大驼峰法

相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。常用于类名，函数名，属性，命名空间。譬如public class StudentInfomation;

补充说明，在JAVA中：类名的标识符一般用大驼峰式书写格式，方法和变量的标识符则多用小驼峰式书写格式。

小驼峰例子：

int myAge;
char myName[10];
float manHeight;

帕斯卡命名法

帕斯卡命名法，又叫大驼峰式命名法。

与小驼峰式命名法的最大区别在于，每个单词的第一个字母都要大写。

例子：

int MyAge;
char MyName[10];
float ManHeight;

下划线命名法

下划线命名法并不如大小驼峰式命名法那么备受推崇，但是也是浓墨重彩的一笔。尤其在宏定义和常量中使用比较多，通过下划线来分割全部都是大写的单词。

该命名规范，也是很简单，要求单词与单词之间通过下划线连接即可。

例子：

int my_age;
char my_name[10];
float man_height;

总结：随着技术的发展，命名规范也在不断的细化，一种命名规范早已无法系统的满足各方需求（匈牙利命名法除外，但是已经基本淘汰了），不同的语言不同 IDE 推崇的规范也有所不同，无法评判哪一种最好，但是可以肯定的是，集后三种命名规范大成者，一定是受众最广的。

例如，谷歌 C++ 编程规范，从项目的命名到文件的命名，再到类和变量以及宏定义的命名都做到了细致入微，充分的结合了下划线命名法与驼峰式命名法（早先推崇的小驼峰，不过今年好像改成大驼峰了），又加入了一些新的元素，十分的系统完善。

当然，命名规范并不代表着编程规范，仅仅是编程规范的一部分而已，除去命名规范，还有很多编程上的细节是必须关注的，例如，等号两边留空格还是等号对齐？空行神马时候神马地方留更加符合代码结构？空格神马时候神马地方留更加美观？花括号是否对齐？

诸如此类，还有很多，无法一下子全部掌握并应用，但是在编程经验增加的过程中，一定也要不断的留意，自己所在的公司部门使用的是神马样的规范，没错，并不提倡大家练就自己的规范，一定要去融入工作环境的需求。

每次去新的工作环境，第一个要看的文档不是别的，一定是编程规范，如果没有这个东西，那么就努力去推一个统一的规范，推不动的话，那可以换工作了，否则日后将会带来无尽的麻烦。