歡迎光臨
每天分享高質量文章

Java 程式設計軍規

(給ImportNew加星標,提高Java技能)

 

作者:Java我人生,

連結:blog.csdn.net/chenleixing/article/details/44173985

 

1、引言:

 

這個標準是衡量程式碼本身的缺陷,也是衡量一個研發人員本身的價值。華為作為一家全球化的 IT 公司,十幾萬員工,無論是人事管理,還是程式碼管理,都是一件不容易的事情,沒有規範的約束,想想都是件可怕的事情。下麵挑選了一些網上流傳的程式設計規範,一起來學習下,以下內容不涉及基礎的語法規範(請見 Refer),更側重於一些程式設計習慣,如何提高程式的健壯性、可維護性等。(PS:以下內容未經官方考證,如閱讀者出現不適,請選擇立即關閉本頁 -_-||| )

 

2、軍規簡介:

 

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

 

軍規二:【明確方法的功能,一個方法僅完成一個功能。】

 

軍規三:【方法引數不能超過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或將浮點數運算轉換為整型運算。】 

 

3、軍規說明

 

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

 

說明:是否是魔鬼數字要基於容易閱讀和便於全域性替換的原則。0、1作為某種專業領域物理量列舉數值時必須定義常量,嚴禁出現類似NUMBER_ZERO的“魔鬼常量”。 

 

軍規二:【明確方法的功能,一個方法僅完成一個功能。】

 

說明:方法功能太多,會增加方法的複雜度和依賴關係,不利於程式閱讀和將來的持續維護,無論是方法還是類設計都應符合單一職責原則。 

 

軍規三:【方法引數不能超過5個】

 

說明:引數太多影響程式碼閱讀和使用,為減少引數,首先要考慮這些引數的合理性,保持方法功能單一、最佳化方法設計,如果引數確實無法減少,可以將多個引數封裝成一個類(物件),同時考慮在新的類(物件)中增加相應的行為,以期更符合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物件都未關閉。推薦做法如下:

 

 

Connection jdbcConnection = null;

       Statement stmt = null;
       try
       {

            ........

       }
       catch(SQLException e)

       {
            ........
       }
       finally
       {
           if(stmt != null)

           {
                try

                {
                    stmt.close();
                }
                catch(SQLException e)

                {
                    logger.log(Level.WARNING,"異常說明", e);
                }
           }
           if(jdbcConnection != null)

           {
                try

                {
                    jdbcConnection.close();
                }
                catch(SQLException e)

                {
                    logger.log(Level.WARNING,"異常說明", e);
               }
           }
       }

 

軍規六:【異常捕獲不要直接 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的其它任何次負冪精確表示為一個長度有限的二進位制小數。

 

具體案例請參考:浮點數加法引發的問題:浮點數的二進製表示

http://my.oschina.net/leejun2005/blog/156793

 

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

 

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

 

1. 小提交: 

 

把大的任務拆分成多個獨立小任務,每完成小任務確保無 Bug 後就可以提交合併到主分支甚至釋出;頻繁提交有利於自己把控專案進度、降低風險、同其他人協作和程式碼 Review ; 每天可以提交合併多次。每個小任務是 1-2 個小時可以完成的粒度,最大的一天完成。並行做多個任務的時候,優先做最短時間能夠實現的任務。

 

2. 命名規範: 

 

儘量避免無意義的字元做變數 比如 a, b, t 。可以逐步改善,可以參考:

http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

 

3. 避免過度設計: 

 

能夠用簡單方式實現的功能,不引入複雜的類,物件,避免不必要的 new 物件,避免引入不必要的泛型、執行緒。開發初期冗餘大於抽象和依賴。避免自己重新實現比較通用的元件和函式。調研多種實現方式的時候,選用做簡單的實現方式。儘量少寫程式碼。

 

4. Web 工程儘量避免在應用內部儲存“狀態”,這樣可以適應頻繁釋出、重啟無影響。

 

5. 善於用打日誌的方式除錯,在程式關鍵點打日誌。儘量少用斷點方式,日誌方式可以批次除錯一批功能,效率相對高。

 

6. 避免一屏顯示不下的超大函式。

 

7. 新增必要、簡潔的註釋:

 

迴圈中的 continue, break 儘量加上單行註釋;儘量避免非函式結尾的 return,必要的時候加註釋。類自動生成 toString() 方法,方便除錯和打日誌

 

8. 不把自己侷限到做某個功能,每個人都是整個專案的 Owner ,儘量交叉 Review ,交叉開發。

 

9. 遇到問題及時和其他人溝通,避免浪費時間。

 

10. 從最終產品的標的審視自己細小的設計,熟悉自己負責部分的上下游程式碼。時刻關註最終產品(Web 介面和日誌),發現 Bug 和可以改善的地方。

已同步到看一看
贊(0)

分享創造快樂