代碼規范很重要，可以提高代碼的可讀性、擴展性、美觀性，也能減少Bug出現率，即使出現也可以很快定位問題，解決問題。
（一）代碼命名規范
- 駝峰命名：類、結構體首字母大寫；方法、參數、變量首字母小寫；常量全部大寫；
- 抽象類以Abstract開頭；枚舉類以Enum結尾；
- 獲取數據以 get 為前綴，例如：getData()；獲取多條數據以 List 為結尾，例如：getAreaList()；插入使用insert為前綴；修改以 update 為前綴；刪除以 del 為前綴；其他方法命名盡量體現業務實現
（二）注釋規范
- 類注釋必須要有，並且每一個類都以實現一個業務操作為基准
- 方法注釋要言簡意賅，通俗易懂，不要有太復雜的邏輯
- 代碼注釋，盡量在代碼塊前進行注釋，不要放到代碼行的后方
- 接口注釋，必須有接口入參及出參說明
（三）HTML規范
- HTML編寫，應當先確定頁面接口，按照結構，由粗到細，逐步填充內容
- 非必要，盡量不要使用 position: absolute、float 等浮動布局，如果確實有必要，建議指定父級的relative，不要在全局定位；float之后，要清除掉浮動，減少因瀏覽器版本導致的布局變動
- 代碼做好縮進，分級編寫，不要在一行內寫入多層結構
（四）JS規范
- 不建議使用 function xxx(){} 這種方式直接創建方法，建議按照分類，創建方法對象 xxx = { aaa:functoin(){}, ...}；例如：加載方法寫在Init對象中，驗證方法寫在Vaile對象中，頁面邏輯寫在 Handle對象中 等
- 如果頁面JS較多，創建以頁面命名的JS，頁面引用JS
- 公共方法中，不使用具體的頁面控件對象，如必須使用，盡量減少單個方法內操作的具體對象數量，不使用單個方法做太多邏輯處理，而是通過多個方法共同實現某一個功能
- 多個公共方法組合實現某個功能時，組合方法不建議作為公共方法，而是用到的地方自己組裝
- 不能方法內部層層嵌套，原則上應該是 業務方法 -> 基礎公共方法，每個頁面的業務方法都要單獨寫，哪怕邏輯相同，也要避免使用公用的業務方法
- 不能再js中進行大量的Html拼接，如有必要，可將html做成部分視圖進行js引用處理
（五）樣式規范
- 樣式也是與HTML相同，先寫全局樣式，再寫模塊樣式，最后寫特殊樣式
- 樣式也要層層嵌套，不建議跳過父級模塊樣式，直接用ID寫樣式，不好控制；
- 減少行內樣式，如想確定某個樣式始終有效，避免被行內樣式覆蓋，在css中添加 !important
- 母版頁的全局樣式，建議單獨css文件編寫，內容頁面樣式較少時，直接在頁面頂部構建頁面單獨的樣式
（六）數據庫規范
- 表命名以 t 為前綴；視圖以 v 為前綴；存儲過程以 p 為前綴；觸發器以 tri 為前綴；
- 表命名使用英文，全部小寫，單詞之間以下划線“_”分隔
- 表名和字段名盡量簡短
- 大長度字段，建議單獨表存儲，通過id管理
- 字段過多時，做表橫向切割，可以按照字段業務來划分，例如 訂單提交信息；訂單流轉控制信息；訂單業務信息等；
- 索引等信息避免大字段；
- 寫修改或者刪除腳本時，先寫條件，在寫要修改或者刪除的語句；修改盡量先查找出來id，通過唯一id進行修改
- count() 和 count(xxx) 語句查詢結果是不一致的，前者是不去null，后者是去除null之后的數據
- 當表較多時，建議按照業務，使用不同的數據庫用戶名（架構名），既方便查找，也方便進行管理
（七）異常規范
- 要區分穩定代碼和非穩定代碼；不能使用try catch包裹所有代碼進行異常捕捉；
- 不能try catch中嵌套try catch，只在非穩定代碼中加try catch
- finally中不能使用return；
- 捕捉異常之后，若吞沒該異常，盡量做好日志記錄
- 若繼續拋出的異常將會脫離框架控制范圍，必須做result套接；例如接口，不能直接將異常拋給客戶或業務端，導致外部資源崩潰；
- 對內業務，建議處理異常並拋出異常提示，對外代碼，建議以代碼Code標識異常類型
- 避免一個異常，多處重復記錄
（八）接口規范
- 接口返回必須有result包裹，不能直接返回data數據
- 接口盡量避免返回null，建議處理成空對象返回；如有需要返回null，需要在接口中注明，並提示接口調用方對返回值做校驗
- 接口架構：可以使用同一個對外接口，根據枚舉類型的不同Code進行，使用IOC分別映射到不同的接口實現類中，好處是可以很方便的對接口請求做控制和驗證，代碼結構也比較整潔有序，后續新增或修改接口時，只需要改動相應的業務即可，無需考慮驗證問題
總結：
每次看到以前寫的代碼，都感覺很渣，這是自己能寫出來的代碼？然后或者默默優化一下，或者直接忽視，等到問題爆發在進行打補丁式的查找修改。
寫這篇文章的目的也是對以前編程的一個回顧，即使到目前為止，上述的很多規范也沒有做到，加以自勉吧！