作者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/m.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