读《代码整洁之道》总结
第一阶段，应该是先把厚书读薄。
第一章： 整洁代码的诸多好处
1.1. 为什么说当下键入的代码就要做到整洁？
“稍后等于永不”。
1.2. 为什么要易读懂的代码？
“如果将编码的过程录下来并快放，会发现大多数时候我们都在不断读上下文并在键入和删除语句之间来回周折。改好代码的前提是，它的上下语句你都读懂了。”
1.3. 什么是整洁的代码？
“整洁的代码只做好一件事”。
总结： 不要重复代码，只做一件事，表达力，小规模抽象。
第二章： 命名要有意义
2.1. 什么样的命名是名副其实的？
“如果名称还需要用额外的注释，那就不是名副其实的”。尝试将一段代码的变量或函数（方法）进行名副其实的改造，你会发现，它变得更加容易维护了。
2.2. 为什么有些区分明显是没有意义的？
“显然，moneyAmount 和 money 是没有区别的，nameString 最好用 name替代就行了，如果你的工程已经在目录下作了比较良好的结构化区分，就没必要在函数或变量前面再添加类似 ms_ 、hw_这样的前后缀了，对读代码的人来说，它是额外的负担。”
variable永远不应该出现在变量的命名上，method func也永远不应该出现在方法/函数名中。
2.3. 还有什么值得注意的？
“用读的出来的名称”。
“不要再对名称进行编码了，这是自找麻烦，在应付代码之外为什么还要再多这么多精力去了解另外一种'语言呢' ”。
“用‘一以贯之’的风格进行命名，你应该不喜欢读一段充满了controller manager driver混用的代码，因为每一个词都那么相近，又似乎表达了不同的含义”。
“起一个技术性的名称。哪一个程序员不知道 JobQueue 的意思呢？”
总结：代码的可读性显然和命名直接相关，要时刻注意在自己的代码中贯彻这些良好的原则。
第三章： 写出有水平的函数
3.1. 函数的首要规则？
“第一规则是短小”。
“第二规则是还要更短小”。
3.2. 怎么做到短小？
“坚持只做一件事；每个函数一个抽象层级”。比如，getHtmlPage( )、String pagePathName = PathParser.render(pagePath)、.append("\n") 就是三个抽象的层级。
“函数的功能越集中，就越便于起一个好的描述性的名字。”
3.3. 什么样的参数比较合理？
“能不用参数就好过用一个参数，能用一个就好过用两个，能用返回值就不要用作为输出的参数！”
“传入标识（flag）参数的做法丑陋不堪，分函数实现吧”。
“实在要用多个参数时，最好能用函数名来区分容易混淆的参数”。比如，assertEquals(message, expected, actual ) 就不如 assertExpectedEqualsActual(expected, actual)来的好。
3.4 慎用参数作为输出，尤其是面向对象的语言中。如果函数必须修改某种状态，就修改所属对象的属性吧。
3.5 什么叫做时序性耦合或顺序依赖？怎样避免函数出现“副作用”？
“函数承诺只做好一件事，但往往也会做出一些未能预期的改动。” 如果在处理过程中，过多掺入对其他部分的改动或判断性的处理，容易导致出现意料之外的处理。
在某个函数执行时，“意外地”改动了系统其他部分的值，导致运行过程中出现了“预料”之外的结果，这就是时序性耦合。
显然，最好的办法还是“坚持只做一件事，并让函数尽可能短小”。
3.6 为什么要分割指令和查询？
boolean set( ) 这样的函数让人捉摸不透。
例如，它在使用时，if(set("username","wang")) 的形式是在问username是否之前已经被设置为"wang"了吗，还是说是否设置为"wang"成功了呢？分割方式如：
if(attributeExists("username")){
setAttribute("username", "wang");
//...
}3.7 其他建议？
别重复自己。
如果发现一段代码重复了许多次，虽然中间有些差异，也应该考虑如何抽离为一个单独的函数。软件开发领域的创新，都是在不断尝试从源代码中消灭重复。
结构化编程。 一个入口，一个出口，最好不要有break 或 continue，更应该少用 goto, 但是只要尽量短小，偶尔出现的这三个语句不一定是有害的，要区注意。
总结：
坚持让函数只做一件事，
给函数一个描述性的名称（最好直接覆盖了函数的实现），
尽量少用参数，尽量不要参数做输出，
小心副作用的处理（容易带来时序性耦合对debug可不是好事），
区分指令和查询，
善于发现重复并抽离为单独的函数。
第四章： 关于注释
4.1. 为什么说注释总是一种失败？
“如果编程语言的代码已经足够表达力，就不需要注释”。
“注释会撒谎”。
注释也不能美化糟糕的代码。
4.2. 用代码阐述
只要稍微花点时间想想，就能用代码解释你的大部分意图。简单到只要创建一个描述与注释所言同一事物的函数即可。
4.3. 什么样的注释是好注释？
“唯一真正好的注释是你想办法不去写的注释”。
“长篇累牍的申明或一些版本控制语句、html等风格的标签，完全没必要，好的注释方式是将它指向某个统一的资源链接”。
4.4. 哪些注释是必须的？
“TODO是必须的，但是尽快处理并删掉它们”。
4.5 为什么不要轻易注释掉代码而应该直接删除？
多数时候，被注释掉的代码，你不会再用它。
无用，但别人不敢轻易删除它。导致坏代码越来越多。
总结：
大多数时候，你的注释都是自说自话，对其他读代码的人来说，往往都是残缺、有误导性的。
想办法把注释用代码来阐述出来吧。