Re: [請益] 寫註解到底是不是好習慣

看板Soft_Job作者 (存取違規)時間5年前 (2018/12/29 21:57), 編輯推噓18(29推 11噓 65→)
留言105則, 51人參與, 6年前最新討論串13/24 (看更多)
這邊怎麼老是吵著小孩子頭上有幾根毛的問題。 說不用註解的，都是英雄主義作祟，自己因為自己的程式碼天下最簡潔易懂，這種看不清 自己的人還挺多的。 團隊合作就是要註解，除非你不在乎團隊！ 你以為大家都是你肚子裡的蛔蟲？ 我光是寫一行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
→
12/29 22:05, 5年前 , 1F
光看一個獨立的數字，就知道為何你需要註解
12/29 22:05, 1F
推
12/29 22:11, 5年前 , 2F
註解不是罪，但是有更多自帶註解的寫法，可以省去維護
12/29 22:11, 2F
→
12/29 22:12, 5年前 , 3F
的心力，例如這種孤獨的數字，應該先define再引用
12/29 22:12, 3F
推
12/29 22:12, 5年前 , 4F
推
12/29 22:12, 4F
→
12/29 22:14, 5年前 , 5F
-4你可以先用有意義的名稱define起來...
12/29 22:14, 5F
→
12/29 22:18, 5年前 , 6F
像是7-11
12/29 22:18, 6F
→
12/29 22:20, 5年前 , 7F
美人維護？？？
12/29 22:20, 7F
→
12/29 22:22, 5年前 , 8F
大家可以說說會用什麼字眼去define那個-4，可以讓
12/29 22:22, 8F
→
12/29 22:22, 5年前 , 9F
我免除那行註解？我覺得怎麼define都不如我那行註
12/29 22:22, 9F
→
12/29 22:22, 5年前 , 10F
解簡單扼要
12/29 22:22, 10F
→
12/29 22:23, 5年前 , 11F
#define MinusFour = -4
12/29 22:23, 11F
→
12/29 22:24, 5年前 , 12F
樓上我笑了
12/29 22:24, 12F
→
12/29 22:24, 5年前 , 13F
#define customersayotmustchangeevery4hr=-4
12/29 22:24, 13F
→
12/29 22:26, 5年前 , 14F
樓上define誤解後人喔，每天清晨四點不是每四小時
12/29 22:26, 14F
→
12/29 22:26, 5年前 , 15F
喔。
12/29 22:26, 15F
推
12/29 22:33, 5年前 , 16F
這篇把為什麼要註解寫的超好
12/29 22:33, 16F
→
12/29 22:34, 5年前 , 17F
用DEFINE也沒註解那一行好
12/29 22:34, 17F
→
12/29 22:40, 5年前 , 18F
AddHours(-4)很難馬上看出來 我會放在function裡
12/29 22:40, 18F
→
12/29 22:42, 5年前 , 19F
或是類似key = shouldReset() ? getNewKey() : key
12/29 22:42, 19F
→
12/29 22:42, 5年前 , 20F
然後把廠商要求那段寫在shouldReset()的block註解
12/29 22:42, 20F
推
12/29 22:50, 5年前 , 21F
timeOfChangingKeyAsHourPerDay = 4; addHours(-tim
12/29 22:50, 21F
→
12/29 22:50, 5年前 , 22F
eOfChangingKeyAsHourPerDay)這樣呢？
12/29 22:50, 22F
推
12/29 22:56, 5年前 , 23F
不管要不要寫注解，都該儘可能讓程式碼本身可達意
12/29 22:56, 23F
→
12/29 22:58, 5年前 , 24F
結果你自己就是你罵的那種人啊～ 不寫註解自以為屌 弄到一
12/29 22:58, 24F
→
12/29 22:58, 5年前 , 25F
堆人來問才加註解 話說你應該是要命一個好的名稱才是 但真
12/29 22:58, 25F
→
12/29 22:58, 5年前 , 26F
的想不到 最少加註解 沒關係 盡力就好
12/29 22:58, 26F
→
12/29 23:00, 5年前 , 27F
就這篇功能的意圖，key可以改名dailyKey，-4可以define
12/29 23:00, 27F
→
12/29 23:01, 5年前 , 28F
為renewTimeOffset之類的，當初如果這樣寫可能不用補
12/29 23:01, 28F
→
12/29 23:01, 5年前 , 29F
注解也不會被煩
12/29 23:01, 29F
→
12/29 23:04, 5年前 , 30F
樓上的例子也不錯
12/29 23:04, 30F
推
12/29 23:07, 5年前 , 31F
像這種東西，應該寫在commit log裡面啦，大哥
12/29 23:07, 31F
→
12/29 23:24, 5年前 , 32F
#define SEVENELEVEN = -4
12/29 23:24, 32F
→
12/30 00:00, 5年前 , 33F
if now >= 04:00 不就好了..是要define什麼?
12/30 00:00, 33F
推
12/30 00:22, 5年前 , 34F
這是典型magic number...
12/30 00:22, 34F
推
12/30 00:30, 5年前 , 35F
這個怎麼會寫在 commit log…一眼能不能分辨差很多好嗎
12/30 00:30, 35F
推
12/30 00:51, 5年前 , 36F
Commit log是讓你寫故事的啊，廠商要求這種東西就是一個
12/30 00:51, 36F
→
12/30 00:51, 5年前 , 37F
商業故事
12/30 00:51, 37F
→
12/30 00:51, 5年前 , 38F
至於你代碼要寫-4 +4 magic number define等等，那千奇
12/30 00:51, 38F
→
12/30 00:51, 5年前 , 39F
百怪，延伸就更多了
12/30 00:51, 39F
還有 26 則推文
→
12/30 08:47, 5年前 , 66F
而且有時也根本是案子一忙一急 註解就「忘了改」不是不改喔
12/30 08:47, 66F
→
12/30 08:47, 5年前 , 67F
平常都有改只是這次「剛好忘了」 阿就是一堆剛好忘了 才造
12/30 08:47, 67F
→
12/30 08:48, 5年前 , 68F
就不可信任的註解啊 XDDDD
12/30 08:48, 68F
→
12/30 08:50, 5年前 , 69F
還有一個副作用就是信任度的問題 只要有幾個地方註解跟code
12/30 08:50, 69F
→
12/30 08:50, 5年前 , 70F
對不起來 會導致你日後再看這個專案時 不信任上面的註解
12/30 08:50, 70F
→
12/30 08:51, 5年前 , 71F
所以一切還是要回歸到人自己的責任上
12/30 08:51, 71F
噓
12/30 09:34, 5年前 , 72F
寫Magic Number的爛扣也敢推上來看啊
12/30 09:34, 72F
推
12/30 10:40, 5年前 , 73F
這篇好笑 拜託你這種人一定要寫註解
12/30 10:40, 73F
噓
12/30 10:42, 5年前 , 74F
小朋友愛寫hard code,還好意思說什麼耳根清靜...
12/30 10:42, 74F
推
12/30 11:04, 5年前 , 75F
你的確蠻需要寫註解
12/30 11:04, 75F
推
12/30 11:42, 5年前 , 76F
這例子明明註解比define好
12/30 11:42, 76F
→
12/30 11:43, 5年前 , 77F
商業邏輯這麼多 每個常數要一個個都def 傻了嗎
12/30 11:43, 77F
推
12/30 11:59, 5年前 , 78F
這個例子我覺得寫得不錯
12/30 11:59, 78F
→
12/30 11:59, 5年前 , 79F
有時候這才是最好的方法
12/30 11:59, 79F
推
12/30 12:00, 5年前 , 80F
能解決問題的就是好方法
12/30 12:00, 80F
噓
12/30 12:02, 5年前 , 81F
還好我不是你同事 不會寫扣去種田
12/30 12:02, 81F
→
12/30 12:03, 5年前 , 82F
-4這種magic number到處亂塞
12/30 12:03, 82F
→
12/30 12:17, 5年前 , 83F
這種設定性數字應該寫去config了 ，hard code害人
12/30 12:17, 83F
推
12/30 12:40, 5年前 , 84F
要一直開commit log來看也太累
12/30 12:40, 84F
推
12/30 12:41, 5年前 , 85F
這個例子是你原本就寫的太爛
12/30 12:41, 85F
噓
12/30 12:44, 5年前 , 86F
config寫在code裡 貴公司哈哈哈哈哈哈哈哈哈哈
12/30 12:44, 86F
噓
12/30 12:53, 5年前 , 87F
最好笑的是這篇就是自介文
12/30 12:53, 87F
噓
12/30 13:43, 5年前 , 88F
自己扣寫這種程度也好意思說別人吵頭上幾根毛
12/30 13:43, 88F
→
12/30 13:47, 5年前 , 89F
真的 config別寫在程式，不然改個設定還要重新編譯
12/30 13:47, 89F
噓
12/30 13:54, 5年前 , 90F
完美示範Magic Number!
12/30 13:54, 90F
→
12/30 15:11, 5年前 , 91F
哇，人家是年薪300萬耶，靠剪貼剪出一片天，在板上發廢文
12/30 15:11, 91F
→
12/30 15:11, 5年前 , 92F
問大家會不會在公司打手槍，(然後被版主水桶)。順便嗆翟
12/30 15:11, 92F
→
12/30 15:11, 5年前 , 93F
本喬技術再強又怎樣。呵呵，繼續放著這篇，別刪文給信徒
12/30 15:11, 93F
→
12/30 15:11, 5年前 , 94F
膜拜吧
12/30 15:11, 94F
→
12/30 19:33, 5年前 , 95F
對！還沒專文批一下翟本喬！感謝提醒！
12/30 19:33, 95F
噓
12/30 21:07, 5年前 , 96F
寫code功力令人佩服...
12/30 21:07, 96F
噓
12/30 22:22, 5年前 , 97F
所有這篇的錯字要不要維護一下？
12/30 22:22, 97F
推
12/31 01:33, 5年前 , 98F
Magic number
12/31 01:33, 98F
→
12/31 14:22, 5年前 , 99F
這篇十分工程 比板上嘴砲強多了
12/31 14:22, 99F
推
01/01 01:10, 6年前 , 100F
推
01/01 01:10, 100F
推
01/03 08:41, 6年前 , 101F
拜託你寫註解
01/03 08:41, 101F
推
01/04 20:38, 6年前 , 102F
推
01/04 20:38, 102F
→
01/04 22:24, 6年前 , 103F
推這篇~這才是現實情況
01/04 22:24, 103F
推
01/05 00:38, 6年前 , 104F
商業邏輯是超脫程式的東西 畢竟不寫出來誰知道啊
01/05 00:38, 104F
噓
01/06 02:21, 6年前 , 105F
我個人認為-4應該寫成變數然後用個好的命名
01/06 02:21, 105F
‣ 更多 accessdenied 的文章
文章代碼(AID): #1S9trDS- (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 13 之 24 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共24篇)
‣ 更多 accessdenied 的文章
文章代碼(AID): #1S9trDS- (Soft_Job)