《代码简洁之道》读书笔记二：注释、格式

下班回来，继续看书。

今天看的是第四章和第五章。

4、注释，平时没少写注释，但是不知道写得对不对，就跟中文翻译一样。作者的解释是注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。

4.1、代码不能美化糟糕的代码。与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。

4.2、用代码来阐述。很多时候，你只需要撞见一个描述与注释所言同一事物的函数即可。

4.3、好注释。有些注释是必须的，也是有利的。

4.4、坏注释。通常，坏注释都是糟糕代码的支撑或借口，或者对错误决策的修正，基本上等于程序员自说自话。例如：多余的注释，如果理解注释的时间多过理解代码的时间，那这段注释还有什么用呢。

看来平时太依赖注释可不是好的习惯，还是应该写出易于理解和好的代码才是王道啊！

5、格式。自我感觉代码的格式非常乱，都是为了完成功能而堆到一起，有必要看看作者如何讲述格式这个话题。

5.1、格式的目的。代码格式关乎沟通，而沟通是专业开发者的头等大事。

5.2、垂直格式，

5.2.1   向报纸学习，多数短小精悍。

5.2..2  概念间垂直方向的区隔

5.2.3  垂直距离，关系密切的概念应该互相靠近。变量声明应尽量靠近其使用位置。循环中的控制变量应该总是在循环语句中声明。实体变量应该在类的顶部声明。相关函数，若某个函数调用了另外一个，就应该把它们放在一起。概念相关的代码应该放在一起。相关性越强，彼此之间的距离就该越短。垂直顺序，自下向上的函数调用关系。

5.3、横向格式

5.3.1  使用空格字符将彼此紧密相关的事物连接到一起，也用空格字符把相关性较弱的事物分隔开。

5.3.2  水平对齐。

5.3.3  缩进。

5.3.4  空范围。有时，while或for语句的语句体为空，尽量不使用，如果无法避免，确保空范围体的缩进，用括号包围起来。

5.4、团队规则，作者用了一张足球场的配图，深得我意。所以讲的是一些团队配合的事情。

差不多可以睡觉了，明天去实践一下今天学到的东西，很好。