本章观点
能不写注释就不写注释,能用代码表示的就用代码表示,不能表示的想办法修改代码表示,实在不行的再使用注释。
在阅读优秀的源码的时候,往往很少有注释。
4.1 注释并不能美化糟糕的代码
如4.2中的代码1,加了注释只会让程序显得更乱。
4.2 用代码来阐述
if((employee.flags & FLAG) &&
(employee.age > 65)){
....
}
对于看别人写的这样的代码时,直接抓狂吧。要看懂if在干什么,太费时,不能然人一目了然。稍稍化几分钟修改一下代码。
if(employee.isEligibleForFullBenefits()){
...
}
很明显,使用类的设计方法,将细节封装成函数,在使用合适的函数名对函数体执行的任务进行说明,这样的设计一眼就能读懂程序在做什么,当需要陷入细节时才去研究对应函数体的实现。
4.3 好的注释
避免坏的代码就是好的代码
4.4 坏的注释
- 多余的注释,没必要写的注释也要写,导致代码看起来混乱。
- 不是所有的变量都需要进行注释说明,信息量不大的注释不用写,最好看到变量名就能知道该变量的作用。
- 举例说明好代码和不好代码的差别,如下。
不好的代码:
好代码:
显而易见,不好代码有几个地方做的不好:
a. 一个函数里面写了太多代码,没有做到简洁、只做一件事和抽象和具体的分层。
b. 因一个函数中的细节过多,不得已使用大量注释去解释代码,造成代码不美观等问题,如果步骤1做的好的话,可以不使用注释,按照功能将长代码改写为短代码,一个功能一个函数实现即可。