※ 引述《accessdenied (存取违规)》之铭言：
: 这边怎么老是吵著小孩子头上有几根毛的问题。
: 说不用注解的，都是英雄主义作祟，自己因为自己的程式码天下最简洁易懂，这种看不清
: 自己的人还挺多的。
: 团队合作就是要注解，除非你不在乎团队！
: 你以为大家都是你肚子里的蛔虫？
: 我光是写一行code：
: key = salt + DateTime.Now.AddHours(-4).ToString(“MMdd”);
: 就会一直有人来问为什么要这样写，-4什么意思？
: 最后我加上一行注解从此耳根清净
: // 厂商要求每天清晨4点以后要更换加密金钥
: 大家讲了半天，注解只有一个缺点，就是过时美人维护。而我认为这才是真正该教育改善
: 的文化和心态：不是我写的注解，所以我没有维护的责任。
: 这才是真正的弊端，而不是倡导clean code。
这个例子举得蛮好的，很多时候我们实务上面对的问题不是单靠命名就可以解决，
因为很多问题没有逻辑性。
比如说我有个机器硬件设计可能有问题，操作100次的时候需要有一个例外操作，
这个code可能会长成:
for(int i = 1 ; i <= 2000; i++){
if(i % 100 == 0){
DoSomethingElse();
}else{
DoSomething();
}
}
这种case你要怎么命名? 这可能是个hardware bug，你确定你要在变量
里面解释这是一个hardware bug吗? 这个case跟上面举的-4基本是同一类的，
你变量再怎么命名都不会比写注解清楚。因为实务上我们会想要提醒接手
的人这个hardware bug长什么样子，如果有做类似的操作要怎么避开，
这不用注解是不大可能做得到的。如果你说可以写在commit log...
ㄛ...我们好像有客户还在用svn...
这种例子我觉得不能算是magic number，本质上不管你怎么define都解释不清楚，
用define的好处就是集中管理方便重用而已。真的要解释中间插两行issue number
简单说一下都好，在那边落落长想code怎么命名花的时间不会比较少，
何况别人读你的code的时候看注解比看code上下文猜容易太多，
这个case就算加了define命名还是需要写注解。
BTW, 程式写注解和做好变量和流程命名根本就不冲突，两者是互补而不是竞争关系。
我不知道这边为什么会有写哪一种比较好的争论，实务上两个都需要，
哪个经济用哪个。
另外我真的觉得很好奇想认真问一下，各位真的觉得那个-4在那边取什么
DailyRest之类的东西绕来绕去有比加一行注解好吗...??
先不要说是不是大砲打小鸟这问题，code没有比较好读啊。