看板 Soft_Job 關於我們 聯絡資訊
這邊怎麼老是吵著小孩子頭上有幾根毛的問題。 說不用註解的,都是英雄主義作祟,自己因為自己的程式碼天下最簡潔易懂,這種看不清 自己的人還挺多的。 團隊合作就是要註解,除非你不在乎團隊! 你以為大家都是你肚子裡的蛔蟲? 我光是寫一行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://www.ptt.cc/bbs/Soft_Job/M.1546091853.A.73E.html
flowheart: 光看一個獨立的數字,就知道為何你需要註解 12/29 22:05
flowheart: 註解不是罪,但是有更多自帶註解的寫法,可以省去維護 12/29 22:11
flowheart: 的心力,例如這種孤獨的數字,應該先define再引用 12/29 22:12
alihue: 推 12/29 22:12
GX90160SS: -4你可以先用有意義的名稱define起來... 12/29 22:14
Csir: 像是7-11 12/29 22:18
eric80295: 美人維護??? 12/29 22:20
accessdenied: 大家可以說說會用什麼字眼去define那個-4,可以讓 12/29 22:22
accessdenied: 我免除那行註解?我覺得怎麼define都不如我那行註 12/29 22:22
accessdenied: 解簡單扼要 12/29 22:22
gino0717: #define MinusFour = -4 12/29 22:23
accessdenied: 樓上我笑了 12/29 22:24
feeya: #define customersayotmustchangeevery4hr=-4 12/29 22:24
accessdenied: 樓上define誤解後人喔,每天清晨四點不是每四小時 12/29 22:26
accessdenied: 喔。 12/29 22:26
orangeterry: 這篇把為什麼要註解寫的超好 12/29 22:33
orangeterry: 用DEFINE也沒註解那一行好 12/29 22:34
yyc1217: AddHours(-4)很難馬上看出來 我會放在function裡 12/29 22:40
yyc1217: 或是類似key = shouldReset() ? getNewKey() : key 12/29 22:42
yyc1217: 然後把廠商要求那段寫在shouldReset()的block註解 12/29 22:42
v420746k: timeOfChangingKeyAsHourPerDay = 4; addHours(-tim 12/29 22:50
v420746k: eOfChangingKeyAsHourPerDay)這樣呢? 12/29 22:50
GX90160SS: 不管要不要寫注解,都該儘可能讓程式碼本身可達意 12/29 22:56
Ghamu: 結果你自己就是你罵的那種人啊~ 不寫註解自以為屌 弄到一 12/29 22:58
Ghamu: 堆人來問才加註解 話說你應該是要命一個好的名稱才是 但真 12/29 22:58
Ghamu: 的想不到 最少加註解 沒關係 盡力就好 12/29 22:58
GX90160SS: 就這篇功能的意圖,key可以改名dailyKey,-4可以define 12/29 23:00
GX90160SS: 為renewTimeOffset之類的,當初如果這樣寫可能不用補 12/29 23:01
GX90160SS: 注解也不會被煩 12/29 23:01
yyc1217: 樓上的例子也不錯 12/29 23:04
oneheat: 像這種東西,應該寫在commit log裡面啦,大哥 12/29 23:07
testPtt: #define SEVENELEVEN = -4 12/29 23:24
x000032001: if now >= 04:00 不就好了..是要define什麼? 12/30 00:00
shownlin: 這是典型magic number... 12/30 00:22
alihue: 這個怎麼會寫在 commit log…一眼能不能分辨差很多好嗎 12/30 00:30
oneheat: Commit log是讓你寫故事的啊,廠商要求這種東西就是一個 12/30 00:51
oneheat: 商業故事 12/30 00:51
oneheat: 至於你代碼要寫-4 +4 magic number define等等,那千奇 12/30 00:51
oneheat: 百怪,延伸就更多了 12/30 00:51
Bencrie: Magic number 讚。寫 commit log 讓後人用 blame 去查 12/30 01:32
Bencrie: 前因後果。 12/30 01:32
kira1101: 我笑了 寫得這麼爛的話真的一定要註解 12/30 01:36
kira1101: 不然真的沒人知道那-4用來幹嘛的 12/30 01:37
qscesz1456: 這種可以寫在config 註解在config就好 改也方便 12/30 03:49
KeyFSN: 天才小釣手是你 12/30 03:51
vi000246: 典型的magic number 12/30 04:36
vi000246: 我會用changeKeyEveryDay當function名 12/30 04:39
drajan: MAGIC NUMBER.....code smell 12/30 06:39
wynight: 笑的人要不要把自己的code貼上來,讓大家review,自以為 12/30 06:41
wynight: 屌? 12/30 06:41
iincho: 這個例子很好啊,有些case寫註解是最省事的資訊傳遞方式 12/30 07:21
iincho: 這個不大能算Magic number,實務上很多case必須這樣搞... 12/30 07:21
iincho: 尤其在商業邏輯部分很多東西用程式角度來看是沒有邏輯的 12/30 07:24
iincho: 這個例子你變數再怎麼命名都不會比加一行註解清楚的... 12/30 07:25
iincho: BTW, 這篇的第一句話跟我對這個版的感想一樣...:p 12/30 08:07
superpai: 典型的不會命名變數只好寫註解 12/30 08:28
Argos: 結果某次commit有人把數字改了註解沒改 然後接手的直接看了 12/30 08:29
weinine32: 推你這篇,說不用註解的人真是自我感覺良好 12/30 08:30
Argos: 註解就當成清晨四點往後寫邏輯 然後就.....XD 12/30 08:30
Argos: 該寫註解的地方當然該寫啦 但我覺得比起寫不寫註解更重要的 12/30 08:31
Argos: 是 註解你要寫 你就要把它當成code的一部份 要改code就是要 12/30 08:31
Argos: 去改註解吧?多少人有只改code 註解卻沒改的惡習? 12/30 08:33
iincho: 連註解都不想維護的會好好維護變數命名...這我不大信... 12/30 08:42
Argos: 寫code的人百百款阿 變數命名已經是普世價值 再白癡的也會 12/30 08:45
Argos: 稍微注意 但維護註解動機可就不像把變數命名好這麼強烈 12/30 08:46
Argos: 而且有時也根本是案子一忙一急 註解就「忘了改」不是不改喔 12/30 08:47
Argos: 平常都有改只是這次「剛好忘了」 阿就是一堆剛好忘了 才造 12/30 08:47
Argos: 就不可信任的註解啊 XDDDD 12/30 08:48
Argos: 還有一個副作用就是信任度的問題 只要有幾個地方註解跟code 12/30 08:50
Argos: 對不起來 會導致你日後再看這個專案時 不信任上面的註解 12/30 08:50
Argos: 所以一切還是要回歸到人自己的責任上 12/30 08:51
askaleroux: 寫Magic Number的爛扣也敢推上來看啊 12/30 09:34
jack42107: 這篇好笑 拜託你這種人一定要寫註解 12/30 10:40
turkeyonly: 小朋友愛寫hard code,還好意思說什麼耳根清靜... 12/30 10:42
sharek: 你的確蠻需要寫註解 12/30 11:04
mmmbop: 這例子明明註解比define好 12/30 11:42
mmmbop: 商業邏輯這麼多 每個常數要一個個都def 傻了嗎 12/30 11:43
lance70176: 這個例子我覺得寫得不錯 12/30 11:59
lance70176: 有時候這才是最好的方法 12/30 11:59
lance70176: 能解決問題的就是好方法 12/30 12:00
deray: 還好我不是你同事 不會寫扣去種田 12/30 12:02
deray: -4這種magic number到處亂塞 12/30 12:03
dali17dali17: 這種設定性數字應該寫去config了 ,hard code害人 12/30 12:17
gmoz: 要一直開commit log來看也太累 12/30 12:40
tvbic: 這個例子是你原本就寫的太爛 12/30 12:41
KanzakiHAria: config寫在code裡 貴公司哈哈哈哈哈哈哈哈哈哈 12/30 12:44
KanzakiHAria: 最好笑的是這篇就是自介文 12/30 12:53
localOjisan: 自己扣寫這種程度也好意思說別人吵頭上幾根毛 12/30 13:43
konkonchou: 真的 config別寫在程式,不然改個設定還要重新編譯 12/30 13:47
showforce: 完美示範Magic Number! 12/30 13:54
rtoday: 哇,人家是年薪300萬耶,靠剪貼剪出一片天,在板上發廢文 12/30 15:11
rtoday: 問大家會不會在公司打手槍,(然後被版主水桶)。順便嗆翟 12/30 15:11
rtoday: 本喬技術再強又怎樣。呵呵,繼續放著這篇,別刪文給信徒 12/30 15:11
rtoday: 膜拜吧 12/30 15:11
accessdenied: 對!還沒專文批一下翟本喬!感謝提醒! 12/30 19:33
sharku: 寫code功力令人佩服... 12/30 21:07
eric80295: 所有這篇的錯字要不要維護一下? 12/30 22:22
rollr: Magic number 12/31 01:33
twntwn: 這篇十分工程 比板上嘴砲強多了 12/31 14:22
zebraseven: 推 01/01 01:10
Aidan79225: 拜託你寫註解 01/03 08:41
remmurds: 推 01/04 20:38
viper9709: 推這篇~這才是現實情況 01/04 22:24
ch890333: 商業邏輯是超脫程式的東西 畢竟不寫出來誰知道啊 01/05 00:38
pig2014: 我個人認為-4應該寫成變數然後用個好的命名 01/06 02:21