打字猴:1.70045335e+09
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
1700453390 此类注释代码完全可以使用版本管理来实现,而不是在生产代码中出现。这里要注意的是,如果代码临时不用(可能在下一版本中使用,或者在生产版本固化前可能会被使用),可以通过注释来解决,如果是废弃(在生产版本上肯定不用该代码),则应该完全删除掉。
1700453391
1700453392 (6)流水账式的注释
1700453393
1700453394 比如有这样的注释:
1700453395
1700453396 /**
1700453397
1700453398 *2010-09-16张三创建该类,实现XX算法
1700453399
[ 上一页 ]  [ :1.70045335e+09 ]  [ 下一页 ]