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