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 的連結放在註解內，讓後人知道這個解法的思路怎麼來。
: 團隊戰不是給這些自命清高不寫註解的小孩子們玩的！