作者accessdenied (存取违规)
看板Soft_Job
标题Re: [请益] 写注解到底是不是好习惯
时间Sat Dec 29 21:57:30 2018
这边怎麽老是吵着小孩子头上有几根毛的问题。
说不用注解的，都是英雄主义作祟，自己因为自己的程式码天下最简洁易懂，这种看不清
自己的人还挺多的。
团队合作就是要注解，除非你不在乎团队！
你以为大家都是你肚子里的蛔虫？
我光是写一行code：
key = salt + DateTime.Now.AddHours(-4).ToString(“MMdd”);
就会一直有人来问为什麽要这样写，-4什麽意思？
最後我加上一行注解从此耳根清净
// 厂商要求每天清晨4点以後要更换加密金钥
大家讲了半天，注解只有一个缺点，就是过时美人维护。而我认为这才是真正该教育改善
的文化和心态：不是我写的注解，所以我没有维护的责任。
这才是真正的弊端，而不是倡导clean code。
一个连别人的注解都不愿维护的人（更糟者连自己的注解都不维护），你期望他修改别人
的function真的负起什麽修改的责任？function功用变了，他回去改function name 然後
把呼叫到这个function的所有程式码都调整过？别傻了孩子！
连注解都懒惰不维护的会跟你搞refactoring？
用不写注解来解决注解过时或错误的问题，根本「掩耳盗铃」嘛！
更何况注解带来的利益，用遇到几个误解的注解，就想要全盘否定，根本以偏概全。
还有一种注解我也常写，我这边的解决手法参考到什麽google 解答，我会把blog or sta
ckoverflow 的连结放在注解内，让後人知道这个解法的思路怎麽来。
团队战不是给这些自命清高不写注解的小孩子们玩的！
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.135.20.48
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1546091853.A.73E.html
1F：→ flowheart: 光看一个独立的数字，就知道为何你需要注解 12/29 22:05
2F：推 flowheart: 注解不是罪，但是有更多自带注解的写法，可以省去维护 12/29 22:11
3F：→ flowheart: 的心力，例如这种孤独的数字，应该先define再引用 12/29 22:12
4F：推 alihue: 推 12/29 22:12
5F：→ GX90160SS: -4你可以先用有意义的名称define起来... 12/29 22:14
6F：→ Csir: 像是7-11 12/29 22:18
7F：→ eric80295: 美人维护？？？ 12/29 22:20
8F：→ accessdenied: 大家可以说说会用什麽字眼去define那个-4，可以让 12/29 22:22
9F：→ accessdenied: 我免除那行注解？我觉得怎麽define都不如我那行注 12/29 22:22
10F：→ accessdenied: 解简单扼要 12/29 22:22
11F：→ gino0717: #define MinusFour = -4 12/29 22:23
12F：→ accessdenied: 楼上我笑了 12/29 22:24
13F：→ feeya: #define customersayotmustchangeevery4hr=-4 12/29 22:24
14F：→ accessdenied: 楼上define误解後人喔，每天清晨四点不是每四小时 12/29 22:26
15F：→ accessdenied: 喔。 12/29 22:26
16F：推 orangeterry: 这篇把为什麽要注解写的超好 12/29 22:33
17F：→ orangeterry: 用DEFINE也没注解那一行好 12/29 22:34
18F：→ yyc1217: AddHours(-4)很难马上看出来 我会放在function里 12/29 22:40
19F：→ yyc1217: 或是类似key = shouldReset() ? getNewKey() : key 12/29 22:42
20F：→ yyc1217: 然後把厂商要求那段写在shouldReset()的block注解 12/29 22:42
21F：推 v420746k: timeOfChangingKeyAsHourPerDay = 4; addHours(-tim 12/29 22:50
22F：→ v420746k: eOfChangingKeyAsHourPerDay)这样呢？ 12/29 22:50
23F：推 GX90160SS: 不管要不要写注解，都该尽可能让程式码本身可达意 12/29 22:56
24F：→ Ghamu: 结果你自己就是你骂的那种人啊～ 不写注解自以为屌 弄到一 12/29 22:58
25F：→ Ghamu: 堆人来问才加注解 话说你应该是要命一个好的名称才是 但真 12/29 22:58
26F：→ Ghamu: 的想不到 最少加注解 没关系 尽力就好 12/29 22:58
27F：→ GX90160SS: 就这篇功能的意图，key可以改名dailyKey，-4可以define 12/29 23:00
28F：→ GX90160SS: 为renewTimeOffset之类的，当初如果这样写可能不用补 12/29 23:01
29F：→ GX90160SS: 注解也不会被烦 12/29 23:01
30F：→ yyc1217: 楼上的例子也不错 12/29 23:04
31F：推 oneheat: 像这种东西，应该写在commit log里面啦，大哥 12/29 23:07
32F：→ testPtt: #define SEVENELEVEN = -4 12/29 23:24
33F：→ x000032001: if now >= 04:00 不就好了..是要define什麽? 12/30 00:00
34F：推 shownlin: 这是典型magic number... 12/30 00:22
35F：推 alihue: 这个怎麽会写在 commit log…一眼能不能分辨差很多好吗 12/30 00:30
36F：推 oneheat: Commit log是让你写故事的啊，厂商要求这种东西就是一个 12/30 00:51
37F：→ oneheat: 商业故事 12/30 00:51
38F：→ oneheat: 至於你代码要写-4 +4 magic number define等等，那千奇 12/30 00:51
39F：→ oneheat: 百怪，延伸就更多了 12/30 00:51
40F：推 Bencrie: Magic number 赞。写 commit log 让後人用 blame 去查 12/30 01:32
41F：→ Bencrie: 前因後果。 12/30 01:32
42F：嘘 kira1101: 我笑了 写得这麽烂的话真的一定要注解 12/30 01:36
43F：→ kira1101: 不然真的没人知道那-4用来干嘛的 12/30 01:37
44F：推 qscesz1456: 这种可以写在config 注解在config就好 改也方便 12/30 03:49
45F：→ KeyFSN: 天才小钓手是你 12/30 03:51
46F：推 vi000246: 典型的magic number 12/30 04:36
47F：推 vi000246: 我会用changeKeyEveryDay当function名 12/30 04:39
48F：推 drajan: MAGIC NUMBER.....code smell 12/30 06:39
49F：推 wynight: 笑的人要不要把自己的code贴上来，让大家review，自以为 12/30 06:41
50F：→ wynight: 屌？ 12/30 06:41
51F：→ iincho: 这个例子很好啊，有些case写注解是最省事的资讯传递方式 12/30 07:21
52F：→ iincho: 这个不大能算Magic number，实务上很多case必须这样搞... 12/30 07:21
53F：→ iincho: 尤其在商业逻辑部分很多东西用程式角度来看是没有逻辑的 12/30 07:24
54F：→ iincho: 这个例子你变数再怎麽命名都不会比加一行注解清楚的... 12/30 07:25
55F：→ iincho: BTW, 这篇的第一句话跟我对这个版的感想一样...:p 12/30 08:07
56F：推 superpai: 典型的不会命名变数只好写注解 12/30 08:28
57F：→ Argos: 结果某次commit有人把数字改了注解没改 然後接手的直接看了 12/30 08:29
58F：推 weinine32: 推你这篇，说不用注解的人真是自我感觉良好 12/30 08:30
59F：→ Argos: 注解就当成清晨四点往後写逻辑 然後就.....XD 12/30 08:30
60F：→ Argos: 该写注解的地方当然该写啦 但我觉得比起写不写注解更重要的 12/30 08:31
61F：→ Argos: 是 注解你要写 你就要把它当成code的一部份 要改code就是要 12/30 08:31
62F：→ Argos: 去改注解吧？多少人有只改code 注解却没改的恶习？ 12/30 08:33
63F：→ iincho: 连注解都不想维护的会好好维护变数命名...这我不大信... 12/30 08:42
64F：→ Argos: 写code的人百百款阿 变数命名已经是普世价值 再白痴的也会 12/30 08:45
65F：→ Argos: 稍微注意 但维护注解动机可就不像把变数命名好这麽强烈 12/30 08:46
66F：→ Argos: 而且有时也根本是案子一忙一急 注解就「忘了改」不是不改喔 12/30 08:47
67F：→ Argos: 平常都有改只是这次「刚好忘了」 阿就是一堆刚好忘了 才造 12/30 08:47
68F：→ Argos: 就不可信任的注解啊 XDDDD 12/30 08:48
69F：→ Argos: 还有一个副作用就是信任度的问题 只要有几个地方注解跟code 12/30 08:50
70F：→ Argos: 对不起来 会导致你日後再看这个专案时 不信任上面的注解 12/30 08:50
71F：→ Argos: 所以一切还是要回归到人自己的责任上 12/30 08:51
72F：嘘 askaleroux: 写Magic Number的烂扣也敢推上来看啊 12/30 09:34
73F：推 jack42107: 这篇好笑 拜托你这种人一定要写注解 12/30 10:40
74F：嘘 turkeyonly: 小朋友爱写hard code,还好意思说什麽耳根清静... 12/30 10:42
75F：推 sharek: 你的确蛮需要写注解 12/30 11:04
76F：推 mmmbop: 这例子明明注解比define好 12/30 11:42
77F：→ mmmbop: 商业逻辑这麽多 每个常数要一个个都def 傻了吗 12/30 11:43
78F：推 lance70176: 这个例子我觉得写得不错 12/30 11:59
79F：→ lance70176: 有时候这才是最好的方法 12/30 11:59
80F：推 lance70176: 能解决问题的就是好方法 12/30 12:00
81F：嘘 deray: 还好我不是你同事 不会写扣去种田 12/30 12:02
82F：→ deray: -4这种magic number到处乱塞 12/30 12:03
83F：→ dali17dali17: 这种设定性数字应该写去config了 ，hard code害人 12/30 12:17
84F：推 gmoz: 要一直开commit log来看也太累 12/30 12:40
85F：推 tvbic: 这个例子是你原本就写的太烂 12/30 12:41
86F：嘘 KanzakiHAria: config写在code里 贵公司哈哈哈哈哈哈哈哈哈哈 12/30 12:44
87F：嘘 KanzakiHAria: 最好笑的是这篇就是自介文 12/30 12:53
88F：嘘 localOjisan: 自己扣写这种程度也好意思说别人吵头上几根毛 12/30 13:43
89F：→ konkonchou: 真的 config别写在程式，不然改个设定还要重新编译 12/30 13:47
90F：嘘 showforce: 完美示范Magic Number! 12/30 13:54
91F：→ rtoday: 哇，人家是年薪300万耶，靠剪贴剪出一片天，在板上发废文 12/30 15:11
92F：→ rtoday: 问大家会不会在公司打手枪，(然後被版主水桶)。顺便呛翟 12/30 15:11
93F：→ rtoday: 本乔技术再强又怎样。呵呵，继续放着这篇，别删文给信徒 12/30 15:11
94F：→ rtoday: 膜拜吧 12/30 15:11
95F：→ accessdenied: 对！还没专文批一下翟本乔！感谢提醒！ 12/30 19:33
96F：嘘 sharku: 写code功力令人佩服... 12/30 21:07
97F：嘘 eric80295: 所有这篇的错字要不要维护一下？ 12/30 22:22
98F：推 rollr: Magic number 12/31 01:33
99F：→ twntwn: 这篇十分工程 比板上嘴炮强多了 12/31 14:22
100F：推 zebraseven: 推 01/01 01:10
101F：推 Aidan79225: 拜托你写注解 01/03 08:41
102F：推 remmurds: 推 01/04 20:38
103F：→ viper9709: 推这篇~这才是现实情况 01/04 22:24
104F：推 ch890333: 商业逻辑是超脱程式的东西 毕竟不写出来谁知道啊 01/05 00:38
105F：嘘 pig2014: 我个人认为-4应该写成变数然後用个好的命名 01/06 02:21