※ 引述《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沒有比較好讀啊。