关于编程中的命名问题

 

         好的代码应该是很好维护的，而代码的可维护性很大程度取决于它的可读性，而提高代码可读性最重要的事情就是重视程序中所有类、函数、变量的命名。以我个人的观点，写程序，最重要的事情就是命名，把命名这个环节做好，好代码自然就来了，反之，不重视命名，或者说胡乱命名，那要想得到好的代码，则是不可能的事情。

         编程中命名既然如此重要，可是要做好却是十分的不容易，下面我总结一些关于命名的规则，如果在编程中都能遵守的话，相信代码质量一定可以大幅提高。

 

1 数据命名为名词，动作命名为动词

         一般而言，类的命名应该用名词，函数应该用动词或动宾和主谓式，而变量自然也应该是名词。我在review 其他人的代码时，先看头文件，重点是头文件中的类和类的方法的命名。好的程序设计，类基本就是描述业务逻辑中的“东西”，熟悉业务逻辑的人，看到这样的“东西”，自然可以很好的理解、掌握和使用。而类的方法即函数，多半是该“东西”能够做的事情。而类中的数据，也应该是名词，它们也是一些“东西”，即类这个“东西”，是由它的内部数据所描述的那些“东西”组成的。

         上面说的比较枯燥，我们举个简单的例子来说。比如用一个公司类来描述一个公司，这个公司包含的各个部门自然就是公司类的内部数据，即公司类由行政部类、销售部类、研发部类、生产部类等组成；而公司的很多经营活动则对应公司类的方法，比如生产某产品、销售某产品、招聘人员等等，还有很多。

 

2 命名要准确

         规则1 很多程序员并没有意识到，但常常自觉的能做到；而规则2，是大家都知道，但常常做不到，或者说很多程序，一开始能做到，做着做着，就越来越做不到了。

         这里说的准确，包含两个意思：函数或者类中不能有命名中没有的动作或者“东西”，也不能缺少名字所包含的概念和动作。这句话比较绕，简单的说就是类和函数的命名要恰当，多了少了都不行。这也正是命名最难做到的地方。

         曾经code review到一个类，名字叫 CConfigManager，这个类的名字字面意思大家都知道，叫配置管理类，可是看它的接口，里面还有很多handle，也还有一个类似 CDlgRecordConfig (录像配置对话框) 的类，我于是把这个类的开发工程师叫过来，问他的设计思路，自然，他总是有自己的道理，但是，他这么做又很显然打破了我们的命名规则。我于是问他，你这个配置管理类都做了什么事情，用一句话描述出来，如果描述不出来，那这个类设计肯定是有问题的，因为好的程序设计，他们的类的功能，都是一句话可以描述的，甚至，有时候就是一个单词就能描述，那个单词就是类的名字。很显然，他的 CConfigManager 不要说用一个词能描述，就是一句话要描述清楚也非常困难，甚至根本就做不到。

         有时候在实际开发过程中，命名必须要有一个持续维护和修改的意识。举个例子来说，假如一开始业务逻辑涉及到了2个概念，分别是土豆和猫咪，程序员为了省事儿，分别用植物类和动物类来命名，这时候并不会产生任何问题，命名我个人觉得也是非常合适和妥当的，某种程度而言，也非常符合敏捷编程的思路。接下来需求有了变更，业务逻辑这时候引入了第三个概念：鸭子，这时候如何对第三个概念命名就是有趣的事情，事实上，常见的情况是工程师对鸭子做了很准确的命名，叫鸭子类，可是，却很少有工程师记得除了要对第三个概念准确命名外，还应当对动物类的命名进行修改，把它改成“猫咪”类，因为如果不修改，后面的工程师看到“动物类”和“鸭子类”时，就会迷茫，程序的可读性自然下降了。

 

3 想不出名字的类和函数，要重新设计

         上面提到的CConfigManager 类，如果功能不变的话，我实在想不出一个准确的名字来给它命名，事实上，这个类的开发者也无法找到。因为这个类不仅仅做了读取配置文件，还做了根据配置文件的配置，对某些handle进行初始化，然后还把录像相关的配置用了一个对话框进行显示，当然，照着这个思路，随着程序的继续开发，这个类还将承担更多别的功能。对这样的类的设计，我的建议是重新设计。我的理论基础很简单：作为一个成年人，我们已经掌握了足够多的词汇，让我们来描述程序所涉及到的任何业务逻辑，只有我们程序员自己在“创造”业务逻辑时，我们才无法进行准确命名，而事实上，程序员的职责是用编程的语言去描述业务逻辑，而不是凭借我们掌握的“独特的语言”去“创造”业务逻辑。如果每个程序员都懂这个道理并应用于开发实践，那我相信，我们软件产品的缺陷数量将下降一个数量！