编程规则与高质量代码

 

         常常听到程序员抱怨他接手的代码比较“烂”，维护起来很吃力，甚至说什么“还不如重新做一遍”等等。这一现象很大程度是因为代码的可读性比较差，而到底应该怎样提高代码的可读性呢？

         我们先来做一个分析，那就是代码为什么普遍存在这可读性不好的弊端。我曾经注意过一个现象，那就是同一个业务逻辑，不同的工程师有着不同的实现方式，即，实现该业务逻辑的代码因为工程师的不同而不同，甚至，同一个工程师因为时间的不同，生产出来的代码也会不同。这个现象其实很有趣，假如一个工程师可以做到在任何时刻，他描述同一个业务逻辑的代码都是完全相同的，那我们可以认为，他是靠着他的习惯来编程的，而不是记忆力。即他不是把他第一次实现该业务逻辑的代码背下来，而是他看到该业务逻辑以后，应用自己的习惯来实现该业务逻辑，如果“习惯”不改变，则每次实现的代码也将不变。把这个习惯放大到团队中的每个程序员，如果程序员的“习惯”都一致，则很显然，他们实现同一个业务逻辑的代码也将是一样的。在实际的开发管理实践中，我把这里所说“编程习惯”称之为“编程规则”。

         最简单常见的“编程规则”就是所谓的“编程规范”，很多公司都有自己的一套包含命名、编程样式等等的规范，从代码的可读性来看，这实在是非常必要的，事实上，真正强力推行并且长期严格执行编程规范的团队都应该能感受到它所带来的好处。

         不过高质量的代码仅仅依赖“编程规范”是远远不够的，其实，我个人的意见是，团队应该注意总结和提炼好的编程方法，并把它文字化，加入到团队的编程规范中。也就是说，团队的编程规范应该有人专门维护，不断加入新的、来自于团队实践的、好的编程方法。这样一个不断完善的“编程规范”，大约就是我所说的“编程规则”。

         上面说了很多，我估计即使有人可以耐心的看完，也很难完全明白我说的变成规则的好处。这里我举个例子来说明。很多C++的工程师在定义类的时候都喜欢以大写的C开头给类命名，比如配置类，就叫做“class CConfig”，如果把这个习惯上升为规则，那会怎样呢？我的建议是从正反两个方面来理解和掌握，大家注意，这里的所谓“正反两个方面”至关重要！所以“正”的方面，指的是规则要求所有的类都应该用大写的C开头，然后紧接着是类描述的事务的名称，该名称第一个字母也大写，注意，这里要求的是“所有的类”！然后接着就是“反”的方面，那就是不是类名，坚决不能用大写的C字母开头。有了这个规则，事实上，程序的可读性毫无疑问的得到了提高，无论是谁来维护这套代码，他看到 CConfig ，都知道这是一个配置类，而不是其他。

         再比如，我们在“关于编程中的命名问题”中曾经提到过一个“规则”，即“类基本就是描述业务逻辑中的‘东西’”，它是名词，表示业务逻辑中客观存在的“东西”。对这个规则，“反”的方面应该怎样理解呢？那应该理解成：所有业务逻辑中客观存在的“东西”，都必须有一个类来描述，如果有“东西”没有类来描述，则代表代码的实现打破了“类的命名”这一规则，它不是一个好的代码实现，需要修改。这里也有个例子来说明一下：某软件的用户配置部分比较复杂，有录像配置、用户名密码配置、UI风格配置、使用习惯配置等等方面，每一个配置都有一个窗口，然后所有这些配置，共用一个 INI文件保存配置。我们的工程师最开始的设计是每个配置窗口一个类，叫什么 CRecordConfigDlg 等等，然后这些窗口类都可以操作INI文件，即读取和保存与它相关的配置。初一看，这样的设计和实现很常见，也没啥大的问题，但是，我却认为它打破了“类的命名”这一规则，即INI文件作为一个客观存在的事务，我们的代码中没有它的映射类，那这样的实现是有问题的，从“代码洁癖”的角度看，这样的代码是不可提交的。后来我们的工程师重新做了实现，增加了一个类用来映射INI配置文件，事实上，经过这样的设计和实现，代码的结构和逻辑变得更清晰了，这个例子证明了三个道理：1 ：“类的命名”这一规则是合理的； 2 ：遵守规则是有很多好处的； 3 打破规则一时爽，但那会破坏代码的可读性。

PS：上面的这个配置类的例子，如果暂时理解不了也很正常；如果能理解，那么恭喜你，你的代码水平和编程境界已经非常高了！