1
wasd6267016 2022-05-30 09:48:05 +08:00 3
高手的好的代码是自注释的
如果做不到,那就多写点注释吧 |
2
NoNewWorld 2022-05-30 09:48:27 +08:00 1
这话是对普通人说的,,牛逼的人写出来的,代码就是注释
|
3
122006 2022-05-30 09:49:49 +08:00 2
自己也需要写注释给几分钟后的自己看
|
4
yuzo555 2022-05-30 09:50:10 +08:00
某种意义上说没错,但充分性和必要性别搞反了。
|
5
dqzcwxb 2022-05-30 09:51:23 +08:00 28
来自 java.lang.Object#toString
|
6
hyqCrystal 2022-05-30 09:53:49 +08:00
看下 spring 的源码 注释确实多,挺好的
|
7
echo1937 2022-05-30 09:55:09 +08:00
高手的代码是自注释的:代码应该简洁易懂,很容易让人明白这段代码是在干什么 -- for what 。
现实工作中代码还应该讲清楚 why ,比如一些业务逻辑的细节,这种需要文档或者注释尽可能详实完备。 |
8
wherewhale 2022-05-30 09:56:42 +08:00
就国内这普遍风气和水平
大部分还是要靠注释理解代码怎么跑的 |
9
clove 2022-05-30 09:56:52 +08:00
可阅读的代码胜过面面俱到的注释。
|
10
retrocode 2022-05-30 09:58:50 +08:00 2
问题在于不同人对"好"的代码定义不同, 以"好"代码为理由不写注释的人, 代码一定不是"好"的代码
|
11
brader 2022-05-30 09:59:38 +08:00 36
还注释,我没在注释里撒谎你就该偷笑了
|
12
wqhui 2022-05-30 09:59:57 +08:00
尽量让人看到函数名或者字段名就知道这是大概做什么的,注释是更详细的解释。遇到命名成屎的函数跟字段,最应做的是重名他们,而不是用一大段注释去解释
|
13
snoopyhai 2022-05-30 10:02:03 +08:00
|
14
Jooooooooo 2022-05-30 10:03:05 +08:00
这和"对绝大多数人来讲, 没到拼天赋的地步"是一个道理.
好的代码风格之类的东西当然重要, 但不如从注释入手. |
15
abersheeran 2022-05-30 10:04:37 +08:00
我就很少写注释。😓除非是写复杂逻辑,否则注释除了让作者和读者都费劲以外,没什么作用。
|
16
akatquas 2022-05-30 10:05:44 +08:00
代码 self-explanatory 是逻辑使然。comment 是业务缘由,也可以用来甩锅。
|
17
gam2046 2022-05-30 10:06:28 +08:00 1
合理。各种优秀的开源项目,都需要大量的注释和文档,Spring 全家桶,没几个人会自己看代码。Android 也同样是看文档,看方法说明就直接上去一把梭。
其他各类语言,.net 啥的,也是以文档、注释优先。似乎只有 C/C++项目,注释量会稍微少一些。 如果你认为自己写代码,没有注释完全也能看得懂,并且自己在一个月后还能知道当时为什么这么写,那就可以不写注释,挑战一下自己。 我尝试过是失败了,两个月后同事问我改需求,自己都看的一愣一愣,心中暗骂自己瓜皮。 |
18
wangtian2020 2022-05-30 10:07:32 +08:00
前端。
自己写的代码不写注释都能很快读懂,对自己个人来说写注释的意义不大。 写注释的好处(作用),可以很快明白一段代码的作用,否则可能需要阅读一会。另外可以给让别人更快理解。 不写注释的好处,省力,这点很重要,没必要上班多干没必要的活。 团队如果有要求就写,没要求就不写,不主动写。 |
19
cmdOptionKana 2022-05-30 10:08:54 +08:00 3
如果问你对 “黄河之水天上来,飞流直下三千尺”,你不会分析是不是真的天上来,具体是多少尺吧?
人类的语言有字面意思,也有修辞手法,比如一种手法叫做“夸张”。 因此我认为,与其只看这句话的字面意思,还不如把它理解为 “注释很重要”,不需要纠结是否一定要比代码多(这也太耿直了吧!) |
20
Leviathann 2022-05-30 10:11:40 +08:00
库代码和业务代码不一样
|
21
thetbw 2022-05-30 10:13:19 +08:00
有些算法可能没有多少注释,变量命名清晰就行,所谓文档就是扔一篇论文给你
|
22
daimubai 2022-05-30 10:15:46 +08:00
注释只写是什么和为什么。如果函数名足够清晰,是什么也可以不写。
|
23
zhazi 2022-05-30 10:18:56 +08:00
注释本身没什么问题。可问题是百分之 90 的人不会写注释。
我看到注释大多类似这样 //这是一只猫 class Cat{} |
24
Building 2022-05-30 10:20:06 +08:00 via iPhone
你注释还没写完,人家需求都改了三遍了,业务类代码和人家框架类代码有什么好比的,业务类只要在有需要解释的地方注释一下为什么这么做就行了
|
25
nothingistrue 2022-05-30 10:21:17 +08:00
敏捷开发出来前,(瀑布式开发年代)这是金科玉律。敏捷开发出来后,这是老顽固和不懂的人才说得出来的话。这里专门指的是代码注释,不包括 Javadoc 这种文档注释。
最后提一点,有没有注释还是好坏的差别,注释跟代码不同步,那是正常跟错误的区别。 |
26
rrZ2C 2022-05-30 10:22:40 +08:00
哈哈,我是真希望 aosp 注释再多一点
|
27
zhazi 2022-05-30 10:24:05 +08:00 7
代码谁都会看,好的注释会告诉你为什么作者会写出以下代码。而不是通过注释重新描述一遍代码
|
28
ebushicao 2022-05-30 10:28:14 +08:00
注释多没用,写的对才有用,有些光写些废话,还不如不写。比如:const sum = a + b; // 将 a 和 b 相加
|
29
Huelse 2022-05-30 10:31:41 +08:00
如果是具有通用性或基础性的代码,当然是有用的注释越多越好
|
30
fredli 2022-05-30 10:31:53 +08:00
好代码是命名规范,逻辑清楚,测试完备,bug free
|
31
qingshuang 2022-05-30 10:33:11 +08:00
虽然我们老讲开闭原则,但是在业务开发中很多地方代码都是需要修改的,但是经常代码被改了,注释没改,这样注释反而有误导信息,所以会说用代码来代替注释。。
|
32
Huelse 2022-05-30 10:34:22 +08:00
比较赞同楼上说的,为什么要写这段代码,可能的改进或可能的问题等,而不是光写这段代码干了啥,例如:获取...,计算...
|
33
ryougifujino 2022-05-30 10:39:38 +08:00 4
业务代码注释反而应该少,且应该自注释。Clean Code 里也说到过:“我为什么要极力贬低注释?因为注释会撒谎。也不是说总是如此或有意如此,但出现得实在太频繁。注释存在的时间越久,就离其所描述的代码越远,越来越变得全然错误。原因很简单。程序员不能坚持维护注释。
代码在变动,在演化。从这里移到那里。彼此分离、重造又合到一处。很不幸,注释并不总是随之变动——不能总是跟着走。注释常常会与其所描述的代码分隔开来,孑然飘零,越来越不准确。” 库代码因为变动程度没那么大,而且有些文档又是根据注释来生成的,所以你会看到大段的注释。 |
34
elintwenty 2022-05-30 10:41:40 +08:00 8
1. 好的开源代码尤其基础类库会写大量注释,包含如何使用、应用背景、关键依赖关系、注意事项等等
2. 差的业务代码可能注释得不到更新,看的人看到的都是过时的、错误的注释,这样还不如没有 3. 简单的代码一看都懂,复杂的代码没有注释、文档、流程图等确定真的可以自解释吗? |
35
ws52001 2022-05-30 10:42:09 +08:00
理论上,开源的代码注释比较多,因为确实是想别人理解更多一点。。商业项目代码,无非就是加个码农名和更新时间,了不得加个更新目的。。
|
36
dqzcwxb 2022-05-30 10:42:48 +08:00
@elintwenty #34 你把问题说清了,很多人都是不在一个频道各说各的
|
37
libook 2022-05-30 10:43:47 +08:00
好的代码是能让人读出智慧的,不是单纯遵循某种硬规则的。
沟通的时候要讲究控制信息密度,信息太少无法准确传达,信息太多又难以让人提炼需要的部分,代码注释也一样。 |
38
encro 2022-05-30 10:44:03 +08:00
代码解析 how ,
注释解析 why 。 理解这句你就什么问题都解决了。 |
39
skys215 2022-05-30 10:44:08 +08:00 1
如果注释是拿来生成文档的,那当然是越多越好吧
不是的话,代码应该能够自表达。对于不符合常理或特殊情况才用注释解释 自表达代码: https://book.douban.com/subject/24858418/ |
40
SeanGeek 2022-05-30 10:54:31 +08:00 1
@wherewhale 不要动不动就“国内”
|
41
aureole999 2022-05-30 10:59:14 +08:00 via iPhone
像 Spring 这种库是让其它人调用的,一般不会去看代码再去使用,这种要写,不过其实这个写的不是注释,而是文档,不然为什么叫 javadoc 。
文档是给用户看的,注释是给自己或自己组里人看的。 |
42
zxxufo008 2022-05-30 11:02:29 +08:00
java 那种源码里很多是为了生成 doc 的
|
43
bruce0 2022-05-30 11:10:21 +08:00
尽量还是代码简短易懂吧, 不要瞎搞骚操作, 我们有个前同事, 用 GO 写代码很喜欢 用 interface 然后再做类型推断, 还喜欢传闭包函数, 就是他写的代码, 很多我不加断点我都不知道跑到哪了. 我还算好的, 有的同事直接看懂不
对于一些复杂的业务逻辑, 没法简化的, 我现在都是把公式写在相关代码前面 |
44
Seayon 2022-05-30 11:10:59 +08:00
最近刚写了一段儿感觉要被同事打的注释,我就是想解释下下面那个参数什么意思。😂
https://s1.ax1x.com/2022/05/30/XldcLt.png |
45
coldmonkeybit 2022-05-30 11:12:20 +08:00
多写注释可以,不过有的人(我同事)改了代码不改注释的,非常离谱
|
46
nicevar 2022-05-30 11:14:50 +08:00
这是对其他人的要求,放自己身上就总觉得不合适
|
47
Seayon 2022-05-30 11:16:27 +08:00
|
48
ryh 2022-05-30 11:21:41 +08:00
看什么项目,开源的自然是越多越好;公司项目也要有标准;个人项目就无所谓了,自己懂就行
|
49
lakehylia 2022-05-30 11:25:40 +08:00
注释不算 KPI ,代码才是 KPI 。如果想要好的注释,那把注释加入 KPI 不就行了。
|
50
zppass 2022-05-30 11:26:47 +08:00
记得看过一句话,冗长复杂的代码的注释,就好像是给后面接手的人一个道歉信
|
51
Felldeadbird 2022-05-30 11:29:24 +08:00
代码是进行时,注释是过去时。
注释容易出现代码变更,但是注释没跟着改的现象。 第一次看《 clean code 》这句话就有很深的印象。 |
52
Orenoid 2022-05-30 11:30:04 +08:00 6
“好的代码不需要注释” 这句话我都快听腻了,然而很多人写的代码并不好
|
53
aguesuka 2022-05-30 11:34:01 +08:00
实际上 5 楼的注释都是文档, 而真正的注释是代码本身. 实际上 Jdk 中从接口到 abstract class 到实现类都符合这样的表现: 注释越来越少, 代码越来越多. 总不能说接口是好代码, 而实现类不是吧.
|
54
emberzhang 2022-05-30 11:34:57 +08:00
写注释的绩效比写代码的绩效多吗。。。
|
55
wupher 2022-05-30 11:35:28 +08:00
评价代码好坏是个复杂问题。有时候,不同时代,不同价值观都可能导致评价结果出现较大偏差。
统计注释 /代码比是个简单方案,很简单就可以通过工具来实现此目的。 通过一个简单方案来粗暴解决一个复杂问题,这种悲剧大家还看的少了?眼前的例子还不够么? |
56
jishu541464750 2022-05-30 11:35:58 +08:00
多看看大的开源库的代码就知道了,应该没人会觉得自己的代码写的比几万 star 的项目的代码更好了吧?
|
57
lujiaosama 2022-05-30 11:37:21 +08:00
业务代码,简练,高密度信息的注释表达清楚为什么这么做还是有必要的, 靠代码猜逻辑还是很痛苦的. 废话注释就免了, 代码有足够的抽象, 良好的命名, 就能让人一看就知道做什么了.
|
58
a570295535 2022-05-30 11:45:47 +08:00
最好是用一句话就说明白这段代码的作用,而不是废话连篇给你复制半本 txt 电子书!
|
59
xinJang 2022-05-30 11:45:54 +08:00
深表认同 方法名就是注释
|
60
aguesuka 2022-05-30 11:55:41 +08:00
大部分语言的标准库里最复杂的算法 -- timsort. 目测代码: 注释 = 10 : 1
https://svn.python.org/projects/python/trunk/Objects/listobject.c |
61
Macolor21 2022-05-30 12:01:22 +08:00 via iPhone
注释是写为什么,而不是写是什么
|
62
AyaseEri 2022-05-30 13:02:22 +08:00
你像 Java 那个 toString ,我表示不可以,一大片绿油油的注释里面夹点代码,readability 为负
|
63
SheHuannn 2022-05-30 13:03:39 +08:00
如果需要大量的注释去解释一段代码,那这段代码可能就需要重构了;好的代码,代码本身就是注释了。
|
64
taest 2022-05-30 13:05:17 +08:00
其实作为中国人,我对汉语的敏感度更高,所以我写中文注释,也喜欢看有注释的代码
|
65
goobai 2022-05-30 13:05:20 +08:00 via Android 1
建议评论区的高手以后都尽量别写注释了😄
|
66
taest 2022-05-30 13:06:06 +08:00
方法名或者参数名写的再好,我还是不如中文注释来的敏感
|
67
adoal 2022-05-30 13:20:24 +08:00
要分清以注释面貌出现、给 external caller 看的文档,和不做为文档、给 internal maintainer / reviewer 看的真正注释
|
68
oldshensheep 2022-05-30 13:20:33 +08:00
|
69
chimission 2022-05-30 13:20:34 +08:00
|
70
greatbody 2022-05-30 13:25:55 +08:00
对于商业项目,如果有 JIRA 或者 AzureDevOps 等卡墙支持,可以考虑在 commit 中指定卡号。这样看起来有疑问的代码就直接去看 commit 记录及相关联的卡。
|
71
springz 2022-05-30 13:38:54 +08:00
业务代码经常修改的不建议写注释,底层代码还是要尽量写单元测试和丰富的注释。
|
72
Hieast 2022-05-30 13:39:03 +08:00
这个得看 ROI 。
如果一段代码预期会被很多人看,比如面向外部的、基础的、框架性质的代码,那么不仅要解释每个参数的含义,还要说明使用场景。甚至按照文档生成工具的标准单独生成文档。 如果一段代码只有开发者看,那么把代码写好就行,实在无法自解释的逻辑加注释。 如果一段代码除了自己谁都不看,比如就自己用的小脚本,那想怎么写怎么写。 |
73
springz 2022-05-30 13:41:03 +08:00
业务代码非常容易出现代码和逻辑改了,注释没同步这种事情。看做的是什么类型的。
|
74
tkHello 2022-05-30 13:41:49 +08:00
资本阶级给无产阶级灌输的观念罢了
|
75
amwyyyy 2022-05-30 13:46:54 +08:00 3
大部分人写的就是一坨屎,还以为自己是好代码不写注释。
|
76
yuancoder 2022-05-30 13:46:58 +08:00
代码本身就在表达你的逻辑
|
77
BigDogWang 2022-05-30 13:50:35 +08:00 4
代码自注释就是扯淡,代码命名、结构好,只能自解释流程,业务细节呢?算法细节呢?不注释看毛线呢
|
78
laviris 2022-05-30 13:54:35 +08:00
对这句话的理解是,需要加上限制条件“在增删改查领域”。稍微运用点算法或者设计,没有注释,也许能看懂,但是有注释可以让看懂的时间缩短到 10%内
|
79
FreshOldMan 2022-05-30 13:56:12 +08:00 1
不少人比较高估自己拉💩的水平,不写注释,怕不是隔了一年,自己都不敢动💩
|
80
QiuXX 2022-05-30 13:59:05 +08:00
我有强迫症就喜欢写注释
|
81
BeautifulSoap 2022-05-30 14:05:12 +08:00 8
说真的,你们学了这么多年业务代码,难道都理解不到代码只能告诉你做了什么,但不会告诉你为什么要这么做的道理吗?
业务代码比注释里写做了什么,写清楚为什么要这么做,这是哪个业务逻辑。尤其是这个业务逻辑对应的资料在哪,链接在哪更加重要 |
82
Biwood 2022-05-30 14:06:51 +08:00 3
注释是为了解释代码本身无法表达的部份,而不是重复代码内容
|
83
shm7 2022-05-30 14:08:48 +08:00
谁说了这句话,下次让他自己在头上贴一张大大的“人”字,不然大家不知道 ta 是人啊。
然后覆盖 20000 字的当前职位职能介绍吧,否则大家不知道他是谁。下班了回家,重写 20000 字。出去玩,重写 20000 字。 |
84
newaccount 2022-05-30 14:16:09 +08:00
写的时候:注释?写个屁的注释!老子的代码是自说明的!
读的时候:卧槽!哪个傻 X 写的代码!特么的注释都不写的啊! |
85
BeautifulSoap 2022-05-30 14:24:56 +08:00
@BeautifulSoap 靠,怎么打字打得错误连篇,重新修正一下:
"说真的,你们写了这么多年业务代码,难道都理解不了代码只能告诉你做了什么,但不会告诉你为什么要这么做的道理吗? 业务代码的注释把为什么要这么做,对应的是哪个业务逻辑,这个业务逻辑对应的资料在哪写清楚更重要。” 最近管理项目知识,深刻意识到了管理好领域知识,并将具体代码和领域知识对应起来是多么重要的一件事 |
87
nightwitch 2022-05-30 14:30:12 +08:00 1
"好的代码不需要注释": 只适用于搬砖代码
复杂点的算法论文十几页都不一定能讲清楚,想靠硬啃代码看懂纯属扯淡 |
88
nanjoyoshino 2022-05-30 14:35:16 +08:00
差不多,尤其是对开源代码,注释详细的读起来真的很舒服
|
89
SimonOne 2022-05-30 14:37:50 +08:00
|
90
FallenTy 2022-05-30 15:04:52 +08:00
希望你们能在半年后不看注释秒懂自己写的代码
|
91
GeruzoniAnsasu 2022-05-30 15:08:16 +08:00
注释是好的
坏注释是坏的 比起「注释比代码多是好的」,「测试代码比逻辑代码多是好的」的准确性更好 |
92
qingshuang 2022-05-30 15:09:57 +08:00
@Seayon 你这里用 payTime 和 id 的联合索引不就好了嘛 payTime>= AND id>
|
93
xuanbg 2022-05-30 15:10:46 +08:00
注释就和日志一样,不好好写非但不起什么作用,反而影响到对代码的正确理解。
|
94
luzemin 2022-05-30 15:14:12 +08:00
|
95
puzzle9 2022-05-30 15:30:34 +08:00
```
$my_girl_friend = function ($self, $girl) { $age = $girl->age; if ($age > 18 && $age < 25) { $height = $girl->height; if ($height > 150 && $height < 180) { $face = $girl->face; if ($face > 60 || !$face) { $money = $girl->money; if ($money || !$money) { // 性格 $character = $girl->character; return $character && $self; } } } } }; $girl = new Girl(...); ``` |
96
zooeymango 2022-05-30 15:52:36 +08:00
代码好不好跟注释的多少不是强相关,一般来说复杂逻辑、传参是需要注释,但是这是因为代码表达不出来这些内容,如果只是单纯复述代码,那就根本不需要加,而且注释也是需要维护的,如果不能同步维护,反而是累赘
|
97
m102 2022-05-30 16:12:32 +08:00
做事用心吧,就像好厨师
做饭前后的 锅 碗 瓢 盆 调 料 厨 具 都码得整整齐齐,干干净净一个道理。 后面轮班的厨师也好开工。 |
98
paoqi2048 2022-05-30 16:17:38 +08:00
反正我写
|
99
DeepRedApple 2022-05-30 16:45:05 +08:00
我觉得只要代码一眼能看出是什么功能的,就不用写代码,如果不是能够马上看出什么功能的,就会写代码,如果涉及到涉及设计模式之类的,也会写。
|
100
chenmobuys 2022-05-30 17:15:14 +08:00
没有什么事情是绝对的,话别说的太死
|