之前就草草的看了一遍项目经理推荐的经典好书《编写可读代码的艺术》。今天闲来无事，又翻阅一下，算是温故而知新。有需要看此书文字版的可以私下或者给我留言。下面为一些重点或梗概。

1.代码应当易于理解：代码的写法应当使别人理解它所需的时间最小化。

2.把信息装到名字里面：清晰和精确比装可爱好。

send: deliver dispatch announce distribute route
find: search extract locate recover
start: launch create begin open
make: create set up bulid generate compose add new

//tmp这个名字只应用于短期存在且临时性为其主要存在因素的变量
//如果你要使用像 tmp it 或者retval这样空泛的名字，那么你要有个好理由

本章唯一的主题是：把信息塞入名字中。
使用专业的单词----例如，不用Get而用Fetch或者Download可能会更好。
避免空泛的名字----像tmp和retval 除非使用它们有特殊的理由。
使用具体的名字来更细致地描述事务----ServerCanStart()这个名字就比CanListenOnPort更不清楚。
给变量名带上重要的细节----例如在值为毫秒的变量后面加上_ms,或者在还需要转移的，未处理的变量前面加上raw_
为作用域大的名字采用更长的名字----不要用让人飞机的一个或两个字母的名字来命名在几屏之间都可见的变量。对于只存在于几行之间的变量用短一点的名字更好。
有目的地使用大小写、下划线等----例如，你可以在类成员和局部变量后面加上"_"来区分它们。

3.不会误解的名字：要多问自己几遍“这个名字会被别人解读成其他含义吗？”

推荐使用min和max来表示(包含)极限
推荐使用first和last来表示包含的范围
推荐使用begin和end来表示包含\排除范围
为布尔值命名时，使用is和has这样的词来明确表示它是个布尔值。

4.审美：看上去很养眼，一致的风格比"正确"的风格更重要

//确切的说,有三条原则：
1.使用一致的布局，让读者很快就习惯这种风格。
2.让相似的代码看上去相似。
3.把相关的代码行分组，形成代码块。

//一些技巧
1.如果多个代码块做相似的事情，尝试让他们又同样的剪影。
2.把代码块按"列"对齐可以让代码更容易浏览。
3.如果在一段代码中提到A、B和C，那么不要在另一段中说B、C和A.选择一个有意义的顺序，并始终用这样的顺序。
4.用空行来把大块代码分成逻辑上的“段落”。

5.该写什么样的注释:注释的主要目的是尽量帮助读者了解和作者一样多。

不要为那些从代码本身就能快速推断的事实写注释。
不要为了注释而注释。
不要给不好的名字加注释--应该把名字改好。

TODO：我还没处理的事情
FIXME：已知的无法运行的代码
HACK：对一个问题不得不采用的比较粗糙的解决方案
XXX：危险，这里有重要的问题。

什么地方不需要注释
1.能从代码本身迅速地推断的事实。
2.用来粉饰烂代码(例如蹩脚的函数名)的“拐杖式注释”--应该把代码改好。

你应该记录下来的想法包括
1.对于为什么代码写成这样而不是那样的内在理由("指导性批注").
2.代码中的缺陷，使用像TODO:或者XXX:这样的标记.
3.常量背后的故事，为什么是这个值。
4.站在读者的立场上思考。

6.写出言简意赅的注释：注释应当有很高的信息/空间率

7.把控制流变得易读.关键思想：把条件、循环以及其他队控制流的改变做的越“自然”越好。运用一种方式使读者不用停下来重读你的代码。

相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间。
默认情况下都用if/else.三目运算符?:只有在最简单的情况下使用。

8.拆分超长的表达式：把你超长的表达式拆分成更容易理解的小块。

9.变量与可读性

变量越多，就越难全部跟踪他们的动向。
变量的作用域越大，就需要跟踪它的动向越久。
变量改变的越频繁，就越难以跟踪它的当前值。

使我们的代码更加“轻量级”和可读性的方法有:
1.减少变量，即使那些妨碍的变量。
2.减小每个变量的作用域，越小越好。
3.只写一次的变量更好。那些只设置一次值的变量(或者const、final、常量)使得代码更容易理解.

10.抽取不相关的子问题:把一般代码和项目专有的代码分开。

11.一次只做一件事

12.把想法变成代码

13.少些代码：最好读的代码就是没有代码，让你的代码库越小，越轻量级越好。

1.从项目中消除不必要的功能，不要过度设计。
2.重新考虑需求，解决版本最简单的问题，只要能完成工作就行。
3.经常性地通读标准库的整个API，保持对他们的熟悉程度。

14.测试与可读性。测试应当具有可读性，以便其他程序员可以舒服地改变或者增加测试。

15.设计并改进"分钟/小时计数器"

阅读的意义就在于引发我们的思考，不动脑筋的阅读，只能称之为消遣。