什么才是代码质量

（原文地址：http://blog.csdn.net/yidinghe/archive/2009/02/06/3863332.aspx，这里做了一些改动。）

什么样的代码才是质量好的？难得有初学者能够注意到这个概念。有人说要有良好的架构，有人说要有清晰的表达，有人说要有足够的测试覆盖率，有人说要有很少的 BUG……五花八门的说法都有。

但是，这些说法，对于一个不知道什么叫架构，不知道什么是测试，甚至不知道什么是 BUG 的初学者来说，有什么意义？在他面前摆出这些空洞的说辞，能让他理解什么是代码质量吗？

所以我觉得应该换一种方式来说明什么是所谓的代码质量，如何写出高质量的代码。

一个初学者，认识的 Java 类没几个，更别说做什么设计了。这样的人能写出这样“高质量”的代码吗？

——能！教你一个简单的原则：不管什么方法都不要超过 5 行。我相信很多人不是第一次见到这句话，但真正把它放在心上的没几个。

我想说的是，初学者要能认准这句话，那就等于练了九阳神功，写出来的代码保证经脉通畅，内劲十足。

不要说做不到。初学者写的程序本来就没多大，一个方法不超过 5 行完全没问题。

具体怎么写呢？举个例子：写一个计算器，main 函数该怎么写？

   
   

    
    
    
    public static void main(String[] args) {
    setupUIManager();                   // 初始化 Swing 风格
    new Calculator().setVisible(true);  // 打开窗体
}
   
   

怎么样，两行。Calculator 就是计算器的窗体类。这个窗体有很多控件，初始化一定有很多代码吧？——NO，不需要：

   
   

    
    
    
    public class Calculator extends JFrame {

    public Calculator() {
        setupFrame(); // 初始化窗体大小、标题等
        createLayout(); // 初始化布局
        createMenu(); // 添加菜单栏
        createTextField(); // 添加文本框
        createButtons(); // 添加按钮
    }
}
   
   

就是这样，通过将代码委派到其他方法，就能把方法缩小到 5 行以内。

看到这里你也许哭笑不得：这搞法未免太弱智了吧？这有什么好处？——这样做的好处就是：总揽全局，快速定位。

拿上面的代码为例，如果将来要添加菜单项，那么一眼就看得出，要修改的只有 createMenu() 方法。如果运行的时候发现少了一个按钮，你也一眼就看得出，问题出在 createButtons() 方法。相反，如果这五个方法参杂在一起，这代码我保证你看了就不想动，如果出了问题要修复，那个头疼啊。。。

不仅如此，更重要的是，这种预先委派的编码方式对你的思维也有提高。

打比方我要做的事情分为若干个步骤。在编写步骤 A 的代码之前，先将 A 委派给一个空的方法 a()。至于 a() 的内容，我现在不考虑，我现在考虑什么？我现在考虑 A 完成之后要做的事情。这就叫三万英尺的高度。

假如 A 做完了就做 B，那么我又将它委派给 b()。以此类推，等所有的事情都委派完了之后，我再考虑 a()、b() 里面该写什么。这个时候，a() 已经把步骤 A 给限定了，传入什么，返回什么，都已经定好了。那么写 a() 的时候根本不用考虑这个方法以外的事情。如果 a() 很复杂，我又可以委派给若干个方法来实现。每个方法都是一样的来做，直到某个步骤已经很简单了，我就可以写最后的代码了。

虽然整个逻辑，A，B，C，D，E，...很复杂，但是通过委派的方式，我每次都只需要考虑其中很小的一部分，所以写起来很轻松。这样写出来的代码脉络清晰，好看又好改。

这就是所谓化整为零，分而治之。所以，一个方法不超过 5 行，不是绝对的，它体现的原则是：一个方法的内容要一眼就能看懂。咱行内有句话：代码是给人看的，不是给机器看的。说句不好听的，不是人看的东西，也一定不是人写的！

你可能会说“没那么严重吧，程序能用就行了嘛”。想想看，如果我愿意，所有的代码都写在 main() 里面，程序不照样能运行？既然能用，我又何必看什么设计模式呢？——所以归根结底，所谓设计，就是将代码组织得更加易懂。易懂的东西才容易复用，容易复用才叫好的设计。

这都是我的切身体会。如果不是当初学编程的时候在书上看到不要超过 5 行这句忠告，我都不敢想象自己现在会是什么样子。所以我特别崇拜这句话，虽然不记得是谁说的……

---

PS1：复杂的方法是可以化简的。如果一个方法“光定义变量就得超过 5 行”，那么可以说，这些变量中大部分实际的作用都是局部的，它们的作用范围只是整个方法的一部分，而这部分就是可以提取出来的。

---

PS2：如何化简长方法，有大师写的专门介绍重构的书。不过本文主题不在于怎么重构，而在于一开始就不要写长方法。 一些 Java 入门书不注重这点，以至于很多人根本不信。总结我个人经历，改代码的时间要比写代码的时间多得多。我改过不少代码，各种风味的都有，包括 6000 多行的类，400 多行的方法。所以我觉得从一开始就要纠正这种陋习，而且必须通过 “不超过 5 行” 这种看似极端的方式来实现。如果你已经有相当的编程经验，或者已经在工作了，那么你以前怎么做的，那就继续做下去，没必要听我唠叨。如果你觉得我居心不良误人子弟，本文出现在 CSDN 首页实在是个祸害，那请赶紧写篇文章驳一驳。

---

PS3：如果你是初学者，你不信，那也没关系。所谓吃一堑方能长一智，经验就是这么来的。要是你看几篇文章几本书就能成熟手，那我们不要混饭吃了。