前一段时间一直在看英文小说,在读到《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代码,真应该好好在开发环境中打开这些代码,跟着书中的思路一步步重构下去。实际上最应该多花些时间认真读读这三章,看看大师如何打磨这些代码的。
第十七章
汇总了书中的各条原则,可以在代码审查时对照它一条一条地进行检查。