“注释也是绩效考核的一部分，虽然没有硬性要求，你们尽量多写。。。”
“代码写得足够好，要什么注释。”
看足了各种书，都在说，变量名字要起好，函数设计要合理，类的职责要单一，接口设计要最小。关于注释的原则也有，不要重复代码，要解释目的，缺点是不易维护，后来的人才不会管前面人写的注释。
这些观点貌似在暗示一个准则：尽量不写注释。这条准则符合了爱写代码不爱写注释的根性，在执行过程中容易被简化为不写注释，且对自己代码的可读性迷之自信。
为什么会这样？
1. 好的注释跟好的代码一样，不好写，很容易就偏离了注释的初衷，过度解读代码，没有解释到位。
2. 注释不可执行，只能靠人工检查，而更没人愿意做这件事情。
3. 注释的作用和缺失的惩罚容易被代码本身掩盖。当你看代码时发出愤怒的 WTF 多半不是针对没有注释，而是在针对代码很烂。
4. 短期内没有收益，注释需要时间才能发挥作用。
5. 注释的直接收益者是团队，而不是个人。走了一个同事，他的注释的价值才具现出来。
怎么整？
别对自己的代码可读性太过自信，名字起得再好，架构设计得再好，也有代码自己解释不了的地方。
对待注释要像代码一样认真，揣着别给未来的自己挖坑的心态去写。
重复前面的话，注释要写目的，写前因后果，不要重复代码能自解释的内容。注释要像鸡腿一样，不要鸡肋。
网友评论