華爲 Java 編程軍規 ！

一、引言

這個標準是衡量代碼自己的缺陷，也是衡量一個研發人員自己的價值。華爲做爲一家全球化的 IT 公司，十幾萬員工，不管是人事管理，仍是代碼管理，都是一件不容易的事情，沒有規範的約束，想一想都是件可怕的事情。下面挑選了一些網上流傳的編程規範，一塊兒來學習下，如下內容不涉及基礎的語法規範（請見 Refer），更側重於一些編程習慣，如何提升程序的健壯性、可維護性等。（PS：如下內容未經官方考證，如閱讀者出現不適，請選擇當即關閉本頁 -_-||| ）

二、軍規簡介

• 軍規一：【避免在程序中使用魔鬼數字，必須用有意義的常量來標識。】

• 軍規二：【明確方法的功能，一個方法僅完成一個功能。】

• 軍規三：【方法參數不能超過5個】

• 軍規四：【方法調用盡可能不要返回null，取而代之以拋出異常，或是返回特例對象（SPECIAL CASE object，SPECIAL CASE PATTERN）；對於以集合或數組類型做爲返回值的方法，取而代之以空集合或0長度數組。】

• 軍規五：【在進行數據庫操做或IO操做時，必須確保資源在使用完畢後獲得釋放，而且必須確保釋放操做在finally中進行。】

• 軍規六：【異常捕獲不要直接catch (Exception ex) ，應該把異常細分處理。】

• 軍規七：【對於if „ else if „(後續可能有多個else if …)這種類型的條件判斷，最後必須包含一個else分支，避免出現分支遺漏形成錯誤；每一個switch-case語句都必須保證有default，避免出現分支遺漏，形成錯誤。】

• 軍規八：【覆寫對象的equals()方法時必須同時覆寫hashCode()方法。】

• 軍規九：【禁止循環中建立新線程，儘可能使用線程池。】

• 軍規十：【在進行精確計算時(例如:貨幣計算)避免使用float和double，浮點數計算都是不精確的，必須使用BigDecimal或將浮點數運算轉換爲整型運算。】

三、軍規說明

• 軍規一：【避免在程序中使用魔鬼數字，必須用有意義的常量來標識。】 說明：是不是魔鬼數字要基於容易閱讀和便於全局替換的原則。0、1做爲某種專業領域物理量枚舉數值時必須定義常量，嚴禁出現相似NUMBER_ZERO的「魔鬼常量」。

• 軍規二：【明確方法的功能，一個方法僅完成一個功能。】 說明：方法功能太多，會增長方法的複雜度和依賴關係，不利於程序閱讀和未來的持續維護，不管是方法仍是類設計都應符合單一職責原則。

• 軍規三：【方法參數不能超過5個】 說明：參數太多影響代碼閱讀和使用，爲減小參數，首先要考慮這些參數的合理性，保持方法功能單1、優化方法設計，若是參數確實沒法減小，能夠將多個參數封裝成一個類（對象），同時考慮在新的類（對象）中增長相應的行爲，以期更符合OOP。

• 軍規四：【方法調用盡可能不要返回null，取而代之以拋出異常，或是返回特例對象（SPECIAL CASE object，SPECIAL CASE PATTERN）；對於以集合或數組類型做爲返回值的方法，取而代之以空集合或0長度數組。】 說明：返回null會增長沒必要要的空指針判斷，遺漏判斷也會致使嚴重的NullPointerException錯誤。

• 軍規五：【在進行數據庫操做或IO操做時，必須確保資源在使用完畢後獲得釋放，而且必須確保釋放操做在finally中進行。】 說明：數據庫操做、IO操做等須要關閉對象必須在try -catch-finally 的finally中close()，若是有多個IO對象須要關閉，須要分別對每一個對象的close()方法進行try-catch,防止一個IO對象關閉失敗其餘IO對象都未關閉。

• 軍規六：【異常捕獲不要直接 catch(Exception ex) ，應該把異常細分處理。】 說明：catch (Exception ex)的結果會把RuntimeException異常捕獲，RuntimeException是運行期異常，是程序自己考慮不周而拋出的異常，是程序的BUG，如無效參數、數組越界、被零除等，程序必須確保不能拋出RuntimeException異常，不容許顯示捕獲RuntimeException異常就是爲了方便測試中容易發現程序問題。

• 軍規七：【對於if „ else if „(後續可能有多個elseif …)這種類型的條件判斷，最後必須包含一個else分支，避免出現分支遺漏形成錯誤；每一個switch-case語句都必須保證有default，避免出現分支遺漏，形成錯誤。】

• 軍規八：【覆寫對象的equals()方法時必須同時覆寫hashCode()方法。】 說明：equals和hashCode方法是對象在hash容器內高效工做的基礎，正確的覆寫這兩個方法才能保證在hash容器內查找對象的正確性，同時一個好的hashCode方法能大幅提高hash容器效率。

• 軍規九：【禁止循環中建立新線程，儘可能使用線程池。】

• 軍規十：【在進行精確計算時(例如:貨幣計算)避免使用float和double，浮點數計算都是不精確的，必須使用BigDecimal或將浮點數運算轉換爲整型運算。】 說明：浮點運算在一個範圍很廣的值域上提供了很好的近似，可是它不能產生精確的結果。二進制浮點對於精度計算是很是不適合的，由於它不可能將0.1——或者10的其它任何次負冪精確表示爲一個長度有限的二進制小數。

四、有關開發效率和協做的幾點建議與心得體會

今天看到某同窗寫給團隊成員的一封郵件，發現比較通用，分享出來吧:

一、小提交:

把大的任務拆分紅多個獨立小任務，每完成小任務確保無 Bug 後就能夠提交合併到主分支甚至發佈；頻繁提交有利於本身把控項目進度、下降風險、同其餘人協做和代碼 Review ; 天天能夠提交合並屢次。每一個小任務是 1-2 個小時能夠完成的粒度，最大的一天完成。並行作多個任務的時候，優先作最短期可以實現的任務。

二、命名規範:

儘可能避免無心義的字符作變量 好比 a, b, t 。能夠逐步改善，能夠參考:http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

三、避免過分設計: 可以用簡單方式實現的功能，不引入複雜的類，對象，避免沒必要要的 new 對象，避免引入沒必要要的泛型、線程。開發初期冗餘大於抽象和依賴。避免本身從新實現比較通用的組件和函數。調研多種實現方式的時候，選用作簡單的實現方式。儘可能少寫代碼。

四、Web 工程儘可能避免在應用內部保存「狀態」，這樣能夠適應頻繁發佈、重啓無影響。

五、善於用打日誌的方式調試，在程序關鍵點打日誌。儘可能少用斷點方式，日誌方式能夠批量調試一批功能，效率相對高。

六、避免一屏顯示不下的超大函數。

七、添加必要、簡潔的註釋：

循環中的 continue, break 儘可能加上單行註釋；儘可能避免非函數結尾的 return，必要的時候加註釋。類自動生成 toString() 方法，方便調試和打日誌。

八、不把本身侷限到作某個功能，每一個人都是整個項目的 Owner ，儘可能交叉 Review ，交叉開發。

九、遇到問題及時和其餘人溝通，避免浪費時間。

十、從最終產品的目標審視本身細小的設計，熟悉本身負責部分的上下游代碼。時刻關注最終產品(Web 界面和日誌)，發現 Bug 和能夠改善的地方。