Java開發過程當中的編碼規範總結

在平常實際開發中咱們須要注意如下方面的編碼規範：

《1》註釋規範：

註釋增長代碼可讀性，便於本身查找問題，也有利於其餘工程師閱讀你的代碼，方便項目的後期維護。通常來講全部的類都要有類註釋，完整的類註釋須要包含：建立者、建立日期、版本、功能描述，若修改過應增長修改者、修改日期、修改功能的簡單描述，變動相應的版本。這是主要的，通常每一個公司都有本身的一套規範，具體細節上會有一些小的差別。

《2》函數規範

函數結構清晰，簡潔，無冗餘代碼。最佳的函數設是一個函數只作一件事，保證函數不出現複用的狀況。對於無用的註釋或者未註釋的代碼予以刪除，冗餘的代碼不只帶來閱讀上的不便，也有可能會干擾正常代碼的閱讀與執行。對於關鍵的業務代碼最好有註釋和設計文檔說明。對於只須要實例化一次的代碼不要放入到循環中作實例化處理，對於嵌套循環終止條件明確，保證代碼在執行後，不管任何情境均可以正常跳出循環。在這一部分須要本身及時作好單元測試，調式代碼，保證功能的準確性，同時須要不斷積累，以本身的實際經驗在編碼時規避一些常見問題，說白了就是寫好代碼的意識，和習慣的創建。

《3》業務邏輯規範

代碼業務邏輯結構合理，簡單明瞭。前期的需求分析，能夠爲爲後來代碼的編寫，減輕很大的壓力，提升效率。通常程序猿多多少少都有過埋怨需求SA的狀況，「需求怎麼又變了，或者需求不明確很差寫代碼」。這都是常見的問題。固然有些狀況避無可避，完美只是理想中的狀態，對於咱們寫程式的人來講，要作好需求變動，修改代碼的心理準備。同時也要求作需求的人提供規範的文檔（如用例圖——能夠得出用戶與系統的交互狀況，主要流程；ER圖——DB關係模型，只針對關係型數據庫；詳細設計文檔從中得出準確的業務流程處理......），這樣才能便於後期的溝通，作到有理有據。

《4》對外接口規範

儘可能以bean或對象的方式對外提供接口訪問，目前多數對外接口都會採用JSON封裝，對於接口最好有詳細的接口文檔，說明清楚版本定義，功能描述，調用方式，字段中文描述，字段可輸入，字段限制等，通常公司開了對外接口的話，都會有相應的API文檔，比較坑的一種狀況是，版本更新，無相應說明。

《5》日誌規範

日誌是咱們查看異常狀況，記錄系統性能參數的好工具，對於日誌文件名最好按日期格式處理，便於查閱和備份，避免日誌覆蓋的狀況發生，正式上線後儘可能去除輸出控制檯的信息輸出，當日志同時輸出文件和控制檯時，在高併發系統中會增長IO的壓力，同時輸出信息時避免先後都有打印換行，當內容增多時，無形中下降程序執行的效率，此外要避免日誌文件集羣共享。這對性能來講影響致命。

《6》SQL編碼規範

理論上SQL執行復雜業務時語句較長，對於其餘人來講閱讀不便，同時頻繁的調用數據庫鏈接池也會大大下降系統效率，但不少狀況下，維護老系統，以及業務須要，SQL來執行增刪改查仍是不可避免，所以若是條件容許儘可能不使用SQL來作操做，取而代之使用像JPA、HQL來執行操做。靈活控制事務的使用，對於只查詢結果的語句，能夠適當下降事務級別，以提高程序執行的效率。數據庫設計合理減小開銷，合理使用索引提升查詢速度，不少公司喜歡使用存儲過程，但卻並非最好的選擇，由於儲存過程易形成移植的不便。大數據量時能夠考慮分批循環查詢，將數據放到List中，而後對List逐筆處理

《7》有完善的差錯處理機制

異常建議打印異常的信息和對應的堆棧信息，有業務邏輯的異常要有響應的編碼，未使用或者使用完的對象要關閉，如輸入輸出流，文件流等。

符合規範的代碼能夠提升自身開發效率，增長代碼可讀性，便於維護和CodeReView，可使測試事半功倍。讓這種意識成爲習慣，以上是我我的的一點小體會，但願對你們有幫助。