clean code 第四章 注释

本章观点
能不写注释就不写注释，能用代码表示的就用代码表示，不能表示的想办法修改代码表示，实在不行的再使用注释。

在阅读优秀的源码的时候，往往很少有注释。

4.1 注释并不能美化糟糕的代码

如4.2中的代码1，加了注释只会让程序显得更乱。

4.2 用代码来阐述

if((employee.flags & FLAG) &&
   (employee.age > 65)){
	....
}

对于看别人写的这样的代码时，直接抓狂吧。要看懂if在干什么，太费时，不能然人一目了然。稍稍化几分钟修改一下代码。

if(employee.isEligibleForFullBenefits()){
	...
}

很明显，使用类的设计方法，将细节封装成函数，在使用合适的函数名对函数体执行的任务进行说明，这样的设计一眼就能读懂程序在做什么，当需要陷入细节时才去研究对应函数体的实现。

4.3 好的注释
避免坏的代码就是好的代码
4.4 坏的注释

1. 多余的注释，没必要写的注释也要写，导致代码看起来混乱。
2. 不是所有的变量都需要进行注释说明，信息量不大的注释不用写，最好看到变量名就能知道该变量的作用。
3. 举例说明好代码和不好代码的差别，如下。
   不好的代码：
   
   好代码：
   
   
   显而易见，不好代码有几个地方做的不好：
   a. 一个函数里面写了太多代码，没有做到简洁、只做一件事和抽象和具体的分层。
   b. 因一个函数中的细节过多，不得已使用大量注释去解释代码，造成代码不美观等问题，如果步骤1做的好的话，可以不使用注释，按照功能将长代码改写为短代码，一个功能一个函数实现即可。