糟糕的代码会渐渐消耗掉对工作的热情以及创造性。若是一个项目是从离职员工那里接手来的，代码的混乱将更是一场灾难。书中的『沼泽』一词让我深有同感，特此记录如何写出高效易读的代码，对书中的观点进行记录与讨论，希望能对开发有所帮助。
第一章 整洁代码
1.何为整洁代码：
大佬们说：
代码逻辑叫缺陷难以隐藏，尽量减少依赖，只做一件事。
不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
可由作者之外的开发者阅读与增补。
看起来像是某位在意它的人写的。
没有重复代码，包括尽量少的实例，比如类、方法、函数。
小规模抽象。
让编程语言像是专为解决那个问题而存在。
。。。
本人认为主要就是易读，易改，精练，少耦合。本人对书中的童子军军规颇为赞同：『让营地比你来的时候更干净』。糟糕的代码会引来更糟糕的代码，类似破窗理论。而好的代码需要开发者的在意与思考，会让开发如虎添翼。
第二章 有意义的命名
1.如果名称需要注释来补充，那就不算是名副其实。
2.避免留下掩藏代码本意的错误线索（避免歧义）。比如别用accountlist来指称一组账号，除非它真的是一个list.List一词对程序员有特殊意义。
3.提防使用不同之处较小的名称。比如AxcdfsController与AsdxcdController就长的很像，容易看错。
4.不要用小写字母l和大写字母O作为变量名。因为看上去很像是数字啊。
5.做有意义的区分。比如ProductInfo和ProductData就让读者不知道有什么区别。
6.使用读的出来的名称。易于开发间的交流。比如genymdhms在交流的时候很难读，改成generationTimestamp就好很多。
7.使用可搜索的名称。单字母名称和数字常量很难在一大篇文字中找出来，故长名称胜于短名称，搜得到的名称胜于自造编码代写就的名称。
8.单字母名称仅用于短方法的本地变量。比如在遍历时经常用到的i,j。名称长短应与其作用域大小相对应。
9.类名和对象名应该是名词或名词短语。如Customer、AddressParser。
10.方法名应该是动词或动词短语。
11.每个概念对应一个词。比如，使用fetch,get,select来给在多个类中的同种方法命名就很难记。
12.别用双关语。比如，add方法是连接两个现存值取得新值。若是一个方法是把一个值加入一个collection中，且也用add,就会混乱。
13.使用解决方案领域的名称。比如，对于熟悉访问者模式的程序员来说，名称AccountVisitor富有意义，就很好。
14.添加有意义的语境。比如对于地址中的firstname，若是单独出现就不知道是什么意思。若是改为addrFirstName,就好很多。当然若是firstname是类address的一个属性，则无需这么改，改了反而累赘。
第三章 函数
1.短小。20行封顶最佳。
2.只做一件事，且每个函数都依序把你带到下一个函数。是否只做一件事可以看是否可以用以『为了』起头的段落来描述这个函数。比如『为了renderpage,要先检查页面是否为测试页，如果是测试页，就容纳进设置和分拆步骤。无论是否测试页，都渲染成html.』如果函数只是做了该函数名下同一抽象层上的步骤，则还是只做了一件事。
3.switch语句，可以用抽象工厂模式来解决。例子：p36
4.使用描述性名称。长而具有描述性的名称，比短而令人费解的名称要好。
5.最理想的参数数量是零。应尽量避免3参数函数。且若参数名与函数名不在同一个抽象层级，它要求你了解目前并不特别重要的细节。再有，参数对测试也不友好。
6。入参用于输入，返回值用于输出。
7.如果函数看来需要两个、三个或三个以上的参数，就说明其中一些参数要封装为类了。
8.无副作用。比如如果一个函数中会删除会话，则需要在命名中说明，否则就是有副作用。
9.将指令与询问分隔。
10.使用异常代替返回错误码。
11.抽离try catch代码块。最好是抽离出来另外形成函数。
12.先写好代码，然后斟酌推敲，直到达到心目中的样子。
13.把系统当作故事来讲，而不是当作程序来写。
未完待续