84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
写了个模块,边写代码边写注释,完了之后发现注释比例接近50%了……关键是,这50%大多是文件、类、属性、方法前面的 JavaDoc,代码流程里面的注释其实不多。我删掉了很多废话,但实在是删不动了。求问,注释比例这么大,是不是程序设计上出现了一些问题?比如模块划分得过细?
闭关修行中......
好代码本身就是注释,至于作者版本信息之类的内容,根本就不应该放在源代码里,话说版本控制系统不就是干这个的么?能一行注释不要又能让别人看懂的代码才是好代码。
PS. API的注释相当于接口文档,这对于公共库来说当然是必需的,要不然没人知道你的库怎么用。
PPS. 注释的目的在于解释代码中无法明示的问题,比如旧版本的兼容性、采用特殊做法/算法原因等,没有目的的注释除了降低代码质量,唯一的用处就是满足领导制定的KPI了。
昨天刚看了华为的java编程规范里面面有说到这个问题:30%
不觉得注释要有一定比例,当你看不懂时,文档就是救命稻草,显然是越多越好!
JavaDoc本身就非常有用的。
我听过一句话,好的代码它本身就是注释。代码如果写得可读性好,其实注释并不那么重要。
注释比例大不大和你的模块设计的合不合理没有直接关系。举个例子来说你看看android Activity的注释和你的比较一下https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/app/Activity.java
能让人比较快的看懂就可以。你可以让另外一个人看,自己在旁边。那个人看不懂哪儿了,你就在那儿加个注释。这样比较合适。
注释要解释的不是这段东西是干嘛的,而是为什么要这么做。
使用注释本身没有严格标准,重在表达含义,提高可读性。
注释多少也成为判定程序好坏的标准了? 我觉得多少得看你的程序会给什么样的人读.
注释也应该遵循80-20原则:
引用Knuth,计算机程序应该是写给人看的,只是恰好可以被计算机执行罢了。从这一点出发,代码应该是主要的内容,而注释就是类似于脚注、备注,大多数情况下不看也不影响原文,关键的地方解释背景、释疑等。
所以不必关心比例。
好代码本身就是注释,至于作者版本信息之类的内容,根本就不应该放在源代码里,话说版本控制系统不就是干这个的么?
能一行注释不要又能让别人看懂的代码才是好代码。
PS. API的注释相当于接口文档,这对于公共库来说当然是必需的,要不然没人知道你的库怎么用。
PPS. 注释的目的在于解释代码中无法明示的问题,比如旧版本的兼容性、采用特殊做法/算法原因等,没有目的的注释除了降低代码质量,唯一的用处就是满足领导制定的KPI了。
昨天刚看了华为的java编程规范里面面有说到这个问题:30%
不觉得注释要有一定比例,当你看不懂时,文档就是救命稻草,显然是越多越好!
JavaDoc本身就非常有用的。
我听过一句话,好的代码它本身就是注释。
代码如果写得可读性好,其实注释并不那么重要。
注释比例大不大和你的模块设计的合不合理没有直接关系。
举个例子来说你看看android Activity的注释和你的比较一下
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/app/Activity.java
能让人比较快的看懂就可以。你可以让另外一个人看,自己在旁边。那个人看不懂哪儿了,你就在那儿加个注释。这样比较合适。
注释要解释的不是这段东西是干嘛的,而是为什么要这么做。
使用注释本身没有严格标准,重在表达含义,提高可读性。
注释多少也成为判定程序好坏的标准了? 我觉得多少得看你的程序会给什么样的人读.
注释也应该遵循80-20原则:
引用Knuth,计算机程序应该是写给人看的,只是恰好可以被计算机执行罢了。从这一点出发,代码应该是主要的内容,而注释就是类似于脚注、备注,大多数情况下不看也不影响原文,关键的地方解释背景、释疑等。
所以不必关心比例。