我們的終極編碼規范，最重要的只有3點：
- 每一個文件不能超過300行代碼，最好不超過200行；
- 每一個方法不能超過30行代碼；
- 不寫一行注釋。
這3點看上去很簡單，但是很多人做不到，即使是多年工作經驗的。我們提出這3點，有很多人不相信做得到，或者認為即使做到實際意義也不大。事實是，我們多個項目成功做到了這3點，我們的團隊深刻體會到了寫代碼的優雅、寫代碼的藝術。
這3點應該在所有項目中遵守，不管是c#，還是js、HTML、java，都應該盡可能達到。
除了這3點，還有其他幾點可供參考：
- 每一個文件夾不能超過30個文件和子文件夾，對於架構而言；
- 業務相關的代碼一定要放到一起；
- 盡可能降低各個類的耦合度；
- 寫任何代碼，當性能不是問題的時候，都應該把代碼寫的更易讀。
命名指導：
對於日期和時間的命名。如果存的值只是日期，那么以Date結尾；如果值是時間，那么以Time結尾。如：CreatedDate代表這條記錄的創建日期，不包含時間；CreatedTime代表這條記錄的創建時間，包含日期和時間。
命名要准確，不可模糊。不能因為命名太長而選擇有歧義或模糊意義的命名。比如以前項目中的一個案例：數據庫中有一個“Recipe（菜）”表，做這個菜的時間包含：PrepareTime, CookTime, OvenTime, CleanTime。這里的命名有問題，因為調用者不知道這里Time是存的秒還是分還是帶小數的小時，於是改成：PrepareMinutes, CookMinutes, OvenMinutes, CleanMinutes。另一個常見例子是，單詞“interval”用作命名的時候，調用者也不清楚是分鍾還是毫秒，於是后面都要加單位。
Bool類型返回值的方法，除了is做前綴外，還有can, will, does, has, should。以前在項目中看到一個方法，叫IsReceiveMessage，我在想是不是IsReceivingMessage，因為很多國內程序員英語語法不好，但后面我看到注釋才發現，這個方法實際上是判斷用戶是否能收到短信，也就是說這個方法應該叫CanReceiveMessage。我相信寫這個方法的程序員，寫完這個方法命名時，肯定自己讀着也感覺不太懂，所以加了個注釋。實際上所有加注釋的地方，要么命名不准確，要么方法太長。一旦你發現自己在寫注釋，那么你就需要思考這2個問題了。
未完待續，本帖長期更新中...