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

光看一個獨立的數字，就知道為何你需要註解註解不是罪，但是有更多自帶註解的寫法，可以省去維護的心力，例如這種孤獨的數字，應該先define再引用

推

-4你可以先用有意義的名稱define起來...

像是7-11

美人維護？？？

大家可以說說會用什麼字眼去define那個-4，可以讓我免除那行註解？我覺得怎麼define都不如我那行註解簡單扼要

#define MinusFour = -4

樓上我笑了

#define customersayotmustchangeevery4hr=-4

樓上define誤解後人喔，每天清晨四點不是每四小時喔。

這篇把為什麼要註解寫的超好用DEFINE也沒註解那一行好

AddHours(-4)很難馬上看出來 我會放在function裡或是類似key = shouldReset() ? getNewKey() : key然後把廠商要求那段寫在shouldReset()的block註解

timeOfChangingKeyAsHourPerDay = 4; addHours(-timeOfChangingKeyAsHourPerDay)這樣呢？

不管要不要寫注解，都該儘可能讓程式碼本身可達意

結果你自己就是你罵的那種人啊～ 不寫註解自以為屌 弄到一堆人來問才加註解 話說你應該是要命一個好的名稱才是 但真的想不到 最少加註解 沒關係 盡力就好

就這篇功能的意圖，key可以改名dailyKey，-4可以define為renewTimeOffset之類的，當初如果這樣寫可能不用補注解也不會被煩

樓上的例子也不錯

像這種東西，應該寫在commit log裡面啦，大哥

#define SEVENELEVEN = -4

if now >= 04:00 不就好了..是要define什麼?

這是典型magic number...

這個怎麼會寫在 commit log…一眼能不能分辨差很多好嗎

Commit log是讓你寫故事的啊，廠商要求這種東西就是一個商業故事至於你代碼要寫-4 +4 magic number define等等，那千奇百怪，延伸就更多了

Magic number 讚。寫 commit log 讓後人用 blame 去查前因後果。

我笑了 寫得這麼爛的話真的一定要註解不然真的沒人知道那-4用來幹嘛的

這種可以寫在config 註解在config就好 改也方便

天才小釣手是你

典型的magic number我會用changeKeyEveryDay當function名

MAGIC NUMBER.....code smell

笑的人要不要把自己的code貼上來，讓大家review，自以為屌？

這個例子很好啊，有些case寫註解是最省事的資訊傳遞方式這個不大能算Magic number，實務上很多case必須這樣搞...尤其在商業邏輯部分很多東西用程式角度來看是沒有邏輯的這個例子你變數再怎麼命名都不會比加一行註解清楚的...BTW, 這篇的第一句話跟我對這個版的感想一樣...:p

典型的不會命名變數只好寫註解

結果某次commit有人把數字改了註解沒改 然後接手的直接看了

推你這篇，說不用註解的人真是自我感覺良好

註解就當成清晨四點往後寫邏輯 然後就.....XD該寫註解的地方當然該寫啦 但我覺得比起寫不寫註解更重要的是 註解你要寫 你就要把它當成code的一部份 要改code就是要去改註解吧？多少人有只改code 註解卻沒改的惡習？

連註解都不想維護的會好好維護變數命名...這我不大信...

寫code的人百百款阿 變數命名已經是普世價值 再白癡的也會稍微注意 但維護註解動機可就不像把變數命名好這麼強烈而且有時也根本是案子一忙一急 註解就「忘了改」不是不改喔平常都有改只是這次「剛好忘了」 阿就是一堆剛好忘了 才造就不可信任的註解啊 XDDDD還有一個副作用就是信任度的問題 只要有幾個地方註解跟code對不起來 會導致你日後再看這個專案時 不信任上面的註解所以一切還是要回歸到人自己的責任上

寫Magic Number的爛扣也敢推上來看啊

這篇好笑 拜託你這種人一定要寫註解

小朋友愛寫hard code,還好意思說什麼耳根清靜...

你的確蠻需要寫註解

這例子明明註解比define好商業邏輯這麼多 每個常數要一個個都def 傻了嗎

這個例子我覺得寫得不錯有時候這才是最好的方法能解決問題的就是好方法

還好我不是你同事 不會寫扣去種田-4這種magic number到處亂塞

這種設定性數字應該寫去config了 ，hard code害人

要一直開commit log來看也太累

這個例子是你原本就寫的太爛

config寫在code裡 貴公司哈哈哈哈哈哈哈哈哈哈最好笑的是這篇就是自介文

自己扣寫這種程度也好意思說別人吵頭上幾根毛

真的 config別寫在程式，不然改個設定還要重新編譯

完美示範Magic Number!

哇，人家是年薪300萬耶，靠剪貼剪出一片天，在板上發廢文問大家會不會在公司打手槍，(然後被版主水桶)。順便嗆翟本喬技術再強又怎樣。呵呵，繼續放著這篇，別刪文給信徒膜拜吧

對！還沒專文批一下翟本喬！感謝提醒！

寫code功力令人佩服...

所有這篇的錯字要不要維護一下？

Magic number

這篇十分工程 比板上嘴砲強多了

推

拜託你寫註解

推

推這篇~這才是現實情況

商業邏輯是超脫程式的東西 畢竟不寫出來誰知道啊

我個人認為-4應該寫成變數然後用個好的命名