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 的连结放在注解内，让后人知道这个解法的思路怎么来。
: 团队战不是给这些自命清高不写注解的小孩子们玩的！