一、規范目的：
規范的目的是提高代碼可讀性，閱讀的舒適性，減少維護的成本，方便后續運維，讓運維人員看到別人寫的代碼就像自己寫的代碼。隨着需求的增加，代碼必然是越堆越多，越來越亂，最后失控導致項目腐爛。物理學上的 熵讓我們理解了一件事，如果不施加外力影響，事物永遠向着更混亂的狀態發展。比如，房間如果沒人打掃，只會越來越亂，不可能越來越干凈。
二、規范要點
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.代碼審查
- 負責人審查
- 小組討論會
規范的關鍵是審查，否則必然會變成形式。引入審查就意味着成本，對中小團隊來說一個月可能一次就足夠了。