一、規範目的：
規範的目的是提高代碼可讀性，閱讀的舒適性，減少維護的成本，方便後續運維，讓運維人員看到別人寫的代碼就像自己寫的代碼。隨着需求的增加，代碼必然是越堆越多，越來越亂，最後失控導致項目腐爛。物理學上的熵讓我們理解了一件事，如果不施加外力影響，事物永遠向着更混亂的狀態發展。比如，房間如果沒人打掃，只會越來越亂，不可能越來越乾淨。
二、規範要點
1.局部變量首字母小寫(Camel)，全局變量統一加下劃線開頭。
- 全局變量統一加下劃線
- 局部變量首字母小寫
2.格式化規範
爲了可讀性，所有的代碼必須格式化。
- 錯誤示範：
中間不要出現無效的空格，影響代碼可讀性。
- 正確示範：
3.枚舉的規範
- 錯誤示範：
- 正確示範：
4.命名規範
命名規範遵循原則：
- 簡單
- 可讀
- 統一
規範是需要成本的。
要做到這三個方面，僅僅是靠規範文檔是很困難的。大家對簡單，可讀，統一的理解各不相同，最後生成的代碼必然是千人前面，所以必須引入代碼審查機制。理論上需要對業務的深入瞭解，需要有很好的英文功底，編程功底的人來做代碼審查是最優選 。
流程：可操作的規範文檔定製和討論==>核心模塊的命名擬定和討論==>資深開發人員的代碼審查==>
4.1常用變量名稱要統一命名。
返回是否成功命名：isSuccess
1)局部變量第一個字母統一小寫
2)是否成功統一下：isSuccess
- 錯誤示範：
- 正確示範：
4.2上層模型命名和底層數據模型保持一致
嚴格按照DB模型爲指導命名，保證整體系統的命名一致性，方面後續運維良好的代碼可讀性。
- 錯誤示範：
該接口是消息回覆，這裏的註釋和命名都是不對的。Replay已經在DB模型出現過，所以必須和DB模型命名保持一致，不能自己另外命名。註釋必須準確，新增消息的註釋和另外一個add接口重複
4.3畫蛇添足
DB命名畫蛇添足，違背了簡單原則
- 錯誤示範：
4.4不要使用語焉不詳的數字
- 除了SQL，儘量不要使用可讀性不好的數字。
4.5複雜不可讀紊亂命名
- 錯誤示範
UserLogin不如LoginaddUser和其他命名大小寫不一致CountryLogo和其他兩個命名結構不一致，一個是名詞，一個是動賓結構。
5.其他細節規範
- 錯誤示範：
- 正確示範：
6.代碼審查
- 負責人審查
- 小組討論會
規範的關鍵是審查，否則必然會變成形式。引入審查就意味着成本，對中小團隊來說一個月可能一次就足夠了。