2015年第11本：代码整洁之道Clean Code

前一段时间一直在看英文小说，在读到《Before I fall》这本书时，读了40%多实在看不下去了，受不了美国人啰啰嗦嗦的写作风格，还是读IT专业书吧。

从5月9日开始看《代码整洁之道》，5月14日完成第一遍的阅读（略掉了并发编程的章节以及两大章重要的JAVA改进的示例），本书中包含大量的有关简洁代码的实用性建议，强烈推荐程序员们（想成为更好的程序员们）必读此书。书中有许多具体的例子，虽然大多是JAVA代码，但对.NET等编程语言同样适用。看完此书后，马上开始对自己手头的代码进行各种各样的重构。现在看到超过200行的源文件就有点不舒服，就想着如何再拆分、简洁一点。这是不是有点简洁过头了？

该书的笔记，有人整理得非常全，从百度上能够搜到这样两篇：

http://blog.csdn.net/john_cdy/article/details/7614564

http://www.cnblogs.com/forlina/archive/2011/06/24/2088603.html

我就不再罗列其中的要点了。我只从每章中挑出一、两条对我影响最大的建议。

前言

书中译者前言中关于“代码猴子”的比喻太形象了。

我们就是一群代码猴子，上蹿下跳，自以为领略了编程的真谛。可惜，当我们抓着几个酸桃子，得意洋洋坐到树枝上，却对自己造成的混乱熟视无睹。那堆“可以运行”的乱麻程序，就在我们的眼皮底下慢慢变坏。

第一章 整洁代码

1.1 程序员也要学习“童子军军规”：让营地比你来时更干净。

如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

1.2 稍后等于永不

我们曾在代码中写下了无数的TODO，说过有朝一日再回头清理，但几年后发现这些代码还是原样。原来LeBlanc说过，“稍后等于永不”(Later equals never)。

1.3 把代码写简洁，才会赶上进度

程序员们迫于期限压力，写出了能够运转的代码，随着功能的不断加入，代码越来越乱，此时解决之道只有两种：逃离此项目，或者让其它人重新写过。程序员们不断地写出一堆堆的代码，为了某个功能变化，复制一个类，改上几行，为了给某个窗口发个消息，把整个form都引用了进来。制造混乱好像一开始很有效果，但长期来看，总体效率将持续下降，直到所有的程序员们都不愿在混乱的代码间穿梭。

第二章 有意义的命名

2.1 起个好名字要花点时间，但绝对值得。一旦发现更好的命名，就换掉旧的。

2.2 类名不应当是动词，要做有意义的区分。例如：如果没有明确约定，Well, WellClass, WellObject, WellInfo, WellData应该是一个东西。

2.3 循环变量可以用i,j,k，但千万别用l。

第三章 函数

3.1 函数要短小，还要更短小，只做一件事，做好这件事。

3.2 函数最好有多长？20行封顶最佳。以现在的显示器大小，也就半屏多。

第四章：注释

4.1 好的名称就是注释，有时多声明几个局部变量，就是好的注释。

我重构之前的代码：

return new cgTransformation(srcRect, destRect, false, true, true);

后面的三个bool变量每次看了都让人抓狂，只需简单加几个局部变量，不用写一行注释，代码可以更清楚。

bool horzFlip = false;
bool vertFlip = true;
bool keepAspectRatio = true;
return new cgTransformation(srcRect, destRect, horzFlip, vertFlip, keepAspectRatio);

不过作者还说了：函数的参数不要超过3个，这条应该很有争议。

4.2 无病呻吟的javadoc式的注释可以去掉。

如果不是生成供第三方使用的类库，许多函数的这类注释都可以删掉。许多这类注释为了注释而注释，很多只是简单地把函数名称翻译成了中文！

我也从我们的项目中随便找了几行，这样的例子太多了：

/// <summary>
/// 从服务端获取客户端程序的当前版本
/// </summary>
/// <returns></returns>
public string GetCurrentClientVersion()
{
…
}

　　

第五章：格式

5.1 每个函数体之间都用空白行隔开

Visual Studio中自带的格式化工具能够完成不少工作，但相当有限。我发现在Visual Studio的插件CodeMaid可以很好地完成这项工作。

5.2 每条代码行的长度不要超过200个字符

我从项目中找了几行代码，在这段代码之前还有三层花括号，长达168个字符，得把滚动条拉到最右边才看清它，想理解它得来回拖动几次滚动条。

if (seismicMapController.SeismicView.Pipeline.SeismicReader.GetTraceMetaData(i - 1).GetField(204).ToString() == cdpNum) 
{ 
    this.seismicMapController.SurveySectionProperty.ViewPosition = new cgPoint(i-1, this.seismicMapController.SurveySectionProperty.ViewPosition.y); 
    break; 
}

　　

第六章：对象和数据结构

6.1 对象和数据结构的反对称性

过程式代码难以添加新的数据结构，因为它要修改所有相关函数。

面向对象的代码难以添加新函数，因为它要修改所有受影响的类。

6.2 Demeter得墨忒耳定律

方法不应调用由任何函数返回的对象的方法。也就是说，只与朋友谈话，不与陌生人谈话。

想遵守这个定律并不太容易，有时为了封装内部细节，就要写出许多重复的代码。

第七章：错误处理

7.1 写一个处理常规流程的函数，把带有大量try-catch的语句单独形成一个函数

7.2 别返回null，别传递null

实在不好办，就在类中写一些类似Point.Empty, Well.Empty的特殊对象。

第八章：边界

可以建立一些单元测试来学习和理解第三方代码，书中称之为“学习性测试(learning tests)”。

有一个好处，当第三方类库出了新版本后，这些代码可以很容易地测试程序包的行为是否发生了改变。

第九章：单元测试

9.1 不仅要写单元测试，还要写许多单元测试，测试驱动开发TDD值得学习

不要以为写单元测试耽误了进度，长远考虑它节省了大量的调试时间，实际是大大提高了效率。好项目的单元测试不是十多个，而是上百个。

9.2 测试代码和产品代码一样重要！仍要写得清晰、简洁、可读。

我们的项目中对单元测试没有硬性要求，一开始还在维护着几个单元测试，几年后发现这些仅有的测试代码也都腐坏了。

第十章：类

10.1 类要短小，还要更短小。

我翻开了项目中的一个超过3000行的类，实在不敢修改其中的一个变量！

实际上Visual Studio 中的#region和#end region语句在鼓励人们写出复杂的类。如果函数和文件都很小，这些语句都是多余的。

10.2 保持内聚性，就会得到更短小的类。（如果发现几个变量经常在一起被几个函数访问，就需要拆分为类了）

10.3 首先要想办法使成员变量保持私有private，放松封装总是下策。

第十一章：系统

构造和使用是非常不一样的过程。AOP我理解不了，但工厂模式还是经常用到的。

第十二章：迭进

Kent Beck的关于简单设计的四条规则：

1）运行所有测试；

2）不可重复；

3）表达了程序员的意图；

4）尽可能减少类和方法的数量。

第十三章：并发编程

略。

第十四至十六章

这几章是关于迭进修改代码的示例，可惜是JAVA代码，真应该好好在开发环境中打开这些代码，跟着书中的思路一步步重构下去。实际上最应该多花些时间认真读读这三章，看看大师如何打磨这些代码的。

第十七章

汇总了书中的各条原则，可以在代码审查时对照它一条一条地进行检查。