1700453340
//默认值为0
1700453341
1700453342
private int num；
1700453343
1700453344
//取值
1700453345
1700453346
public int getNum（）{
1700453347
1700453348
return num；
1700453349
1700453350
}
1700453351
1700453352
//输入int类型变量，无返回值
1700453353
1700453354
public void setNum（int num）{
1700453355
1700453356
this.num=num；
1700453357
1700453358
}
1700453359
1700453360
public void doSomething（）{
1700453361
1700453362
//自增
1700453363
1700453364
num++；
1700453365
1700453366
}
1700453367
1700453368
}
1700453369
1700453370
以上四个注解是不必注释的典型代表（本书的代码上也有一些类似的注释，只是为了阐明代码片段，不用作生产代码）：
1700453371
1700453372
第一个默认值完全没有必要说明，相信代码的阅读者这点智商还是有的，他应该明白实例变量初始值为0，即使加上个初始值也完全没有必要注释，除非有特殊含义。
1700453373
1700453374
第二个注释在get方法上，如此简单的代码，看代码比看注释所花费的时间长不了多少，不要低估了代码阅读者（很可能就是你，代码的编写者）的智商。
1700453375
1700453376
第三个注释描述了输入和输出参数类型，相信IDE吧，相信它会这么“智能化”的提示吧（基本上每个IDE都能实现输入补全和输入输出提示）！不需要我们手工撰写。这些注释难道是为那些用记事本编写代码的狂人准备的？可是在看到输入的int类型，输出的void后，难道他还不能明白吗？—注释完全多余了。
1700453377
1700453378
第四个注释也蔑视了代码阅读者的智商，这是编码的最基本算法，不用注释。
1700453379
1700453380
（4）过时的注释
1700453381
1700453382
注释与代码的版本不一致，注释是1.0版本，而代码早已窜到了5.0版本，相信读者对此类注释深有感触：代码一直在升级，但注释永远保持不变，直到有一天，某一个“粗心”的家伙根据注释修正了一个代码缺陷，然后发现产生了连锁的缺陷反应才知道“代码世界”已经早已发生了变化，而此处的注释只是描述了最原始的信息。
1700453383
1700453384
这类注释不仅仅会出现在你我的代码中，同时也会出现在一些非常著名的开源系统中，毕竟注释不参与运行，只是给人看的，修改代码而不修改注释照样可以运行，添加注释只是“额外任务”而已。解决此类问题的最好办法就是保持注释与代码同步。
1700453385
1700453386
（5）大块注释代码
1700453387
1700453388
可能是为了考虑代码的再次利用，有些大块注释掉的代码仍然保留在生产代码中，这不是一个好的习惯，大块注释代码不仅仅影响代码的阅读性，而且也隔断了代码的连贯性，特别是在代码中的间隔性注释，更增加了阅读的难度，会使Bug隐藏得更深。
1700453389
[
上一页 ]
[ :1.70045334e+09 ]
[
下一页 ]