命名法的思考

        工作很久很久后，偶尔翻开书，才发现自己对命名规范依旧没有自己的思考，都是人云亦云。没有思考到底哪种更合适。今天看到cleancode里面几点建议：不建议匈牙利标记、成员前缀、接口前缀。都是希望编码的附加信息尽量避免包含在变量名中。这样到底适不适合我们？尤其是大型中国项目。

       基于我的工作经验：我觉得命名规范应该遵循以下几点，可以减轻大家维护代码的工作，减少wtf/min的次数。

       1.规则一定要统一（就跟身份证样式一样，一定要一套样式，否则维护起来很麻烦）。统一是优先级最高且最重要的一项标准。很多大型项目这方面是最欠缺的。

       2.统一的基础上，规则应尽量简单。比如尽量不要加前缀描述，尤其是新员工比较多的，培训前缀的成本会比较大，大家阅读代码也会增加成本。

       3. 变量名应该自解释，但不要过长。所以个人认为小驼峰法比下划线法更合适。  

注意：该规范仅适用以下前提（干什么事情都记得不要以偏概全，中庸之道）：项目人员较多；项目流动性比较大；项目研发人员能力参差不齐；项目工程比较大。

附几个基本概念命名法概念：驼峰命名法、下划线命名法、匈牙利命名法。

一、骆驼命名法：

1）小驼峰法（camel方法）变量一般用小驼峰法标识。

第一个单词以小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母，例如：myFirstName、myLastName

2）大驼峰法（Upper Camel Case）也称为：帕斯卡命名法：（pascal方法）常用于类名，函数名，属性，命名空间。

相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。例如：public class DataBaseUser

二、下划线命名法： 

用下划线区分字母。

下面是分别用骆驼式命名法和下划线法命名的同一个函数：

printEmployeePaychecks()；骆驼式命名法——函数名中的每一个逻辑断点都有一个大写字母来标记

print_employee_paychecks()；下划线法----函数名中的每一个逻辑断点都有一个下划线来标记。

三、匈牙利命名法：

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