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

[ripple0129 (perry tsai)]

AddHours(CUSTOMER_REQUIRED_ADJUST_HOURS)
這種還有解
有些很難解的一定要註解了
不過這邊本來就該define搬出來
哪時候換時間直接去調整這個程式碼不是明確之舉
會讓程式碼違反Open Close

而如果程式碼有測試
改動測試碼就跟著出錯
assert(inputHours, expectedHours+CUSTOMER_REQUIRED_ADJUST_HOURS)

※ 引述《accessdenied (存取違規)》之銘言：
: 這邊怎麼老是吵著小孩子頭上有幾根毛的問題。
: 說不用註解的，都是英雄主義作祟，自己因為自己的程式碼天下最簡潔易懂，這種看不
清
: 自己的人還挺多的。
: 團隊合作就是要註解，除非你不在乎團隊！
: 你以為大家都是你肚子裡的蛔蟲？
: 我光是寫一行code：
: key = salt + DateTime.Now.AddHours(-4).ToString(“MMdd”);
: 就會一直有人來問為什麼要這樣寫，-4什麼意思？
: 最後我加上一行註解從此耳根清淨
: // 廠商要求每天清晨4點以後要更換加密金鑰
: 大家講了半天，註解只有一個缺點，就是過時美人維護。而我認為這才是真正該教育改
善
: 的文化和心態：不是我寫的註解，所以我沒有維護的責任。
: 這才是真正的弊端，而不是倡導clean code。
: 一個連別人的註解都不願維護的人（更糟者連自己的註解都不維護），你期望他修改別
人
: 的function真的負起什麼修改的責任？function功用變了，他回去改function name 然
後
: 把呼叫到這個function的所有程式碼都調整過？別傻了孩子！
: 連註解都懶惰不維護的會跟你搞refactoring？
: 用不寫註解來解決註解過時或錯誤的問題，根本「掩耳盜鈴」嘛！
: 更何況註解帶來的利益，用遇到幾個誤解的註解，就想要全盤否定，根本以偏概全。
: 還有一種註解我也常寫，我這邊的解決手法參考到什麼google 解答，我會把blog or s
ta
: ckoverflow 的連結放在註解內，讓後人知道這個解法的思路怎麼來。
: 團隊戰不是給這些自命清高不寫註解的小孩子們玩的！

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.171.204.87
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1546093693.A.583.html
推 flowheart: 真好心
推 Ghamu: 是啊 所以不用註解惹～
推 Ghamu: 沒啦 只是你看ac不就是程式沒寫好 不用命名一個好的常數 讓
→ Ghamu: 後人不知道意圖才寫註解的嗎?
→ Ghamu: 是說真的不行了 想不到怎麼寫 才寫我沒意見
→ accessdenied: 能一行註解搞定的事情，幹嘛要在那邊絞盡腦汁想怎
→ accessdenied: 樣寫法可以不寫註解？生產力花這上面好嗎？
推 GX90160SS: 錯了吧，就是凡事都想補註解才會不考慮程式碼本身能否
→ GX90160SS: 達意，造成只看程式碼看不懂非給要看註解才能懂
→ t64141: GX大在上篇推的做法不錯阿
推 Ghamu: 有人就喜歡多花時間寫註解 維護註解 註解不小心過時誤導開
→ Ghamu: 發人員 還要有摸過沒更新註解的人來鞭 如果那個人離職了 你
→ Ghamu: 就是滿手爛扣配上過時註解 慘   詞不達意 過時資訊 溝通成
→ Ghamu: 本才是真正耗費生產力的主因