編碼規范建議

任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程序員  --Martin Flower

1、重復代碼

      如果在一個以上的地方看到相同的程序結構，那么設法將它們合而為一，程序會變得更好。

    將大的函數拆分成小的方法，可以在一定程度上減少代碼重復，提高代碼利用率。

2、過長函數

      應該積極地分解函數。每當感覺需要以注釋來說明點什么的時候，我們就把需要說明的東西寫進一個獨立函數中，并以其用途（而非實現手法）命名。

       定義的變量名稱，方法名稱，類名稱以及JSP名稱等應該具有一定的意義。不要定義類似a1，a2，abc…這類沒有意義或意義不明顯的變量。

3、過大的類

      如果想利用單個類做太多的事情，其內往往就會出現太多實例變量。一旦如此，重復代碼問題也就接踵而至了。應該按職能的不同將其細化為多個小類或子類。

4、過長參數列表

      太長的參數列表難以理解，而且容易造成前后不一致，不易使用。應該將對象傳遞給函數，你只需要在函數內調用getXXX方法，就能得到更多數據。

5、發散式變化

如果某個類因為不同的原因在不同的方向上發生變化，發散式變化便產生了。應該在不同方向上將其拆分為不同的子類。

6、散彈式修改

      如果每遇到某種變化，你都必須在許多不同的類內做許多小修改，你所面臨的問題就是散彈式修改。應該把所有需要修改的代碼放進同一個類中，使得“外界變化”與“需要修改的類”趨于一一對應。

      對于可以引起修改的地方，應該集中在某個地方，而不要到處亂放。（例如：實例里面Bean中的獲取Request參數方法）

7、依戀情結

      函數對某個類的興趣高過對自己所處類的興趣。如果一個函數內的大部分操作需要調用其他類的操作，應該將這個函數移至其他類中。

8、數據泥團

      如果常常可以在很多地方看到相同的三四項數據（如：兩類中相同的字段、許多函數簽名中相同的參數）。應該將這些數據項提煉到一個獨立的對象中。

9、基本類型偏執

      如果需要使用多個基本類型表達一個數據組或數據結構的概念，那么應該將這些基本類型組合成小的對象。

10、Switch

      面向對象程序的最明顯的特性就是：少用switch語句。應該使用面向對象中的多態概念解決此類問題。

11、冗贅類

      如果一個類的存在沒有價值，就應該將其刪除。

12、夸夸其談未來性

      如果一個類是為了未來的需要而設置的，暫時用不到，你應該將其移去。

13、暫時字段

      如果某個實例變量僅為某種特定情況而設（例如為了某個特定算法的需要），這樣的代碼讓人不易理解。應該新建一個類，將這個變量和與這個變量相關的代碼都放進這個類中。

       在變量使用前定義變量，而不要再方法一開始就定義一大堆變量。

14、過度耦合的消息鏈

      如果一個對象的請求需要通過一系列的消息鏈轉發，這時，一旦對象間的關系發生任何變化，客戶端就不得不做相應的修改。

15、中間人

      如果一個類接口有一半的函數都委托給了其他類，這樣就是過度運用了委托。應該直接和真正負責的對象打交道。

16、異曲同工類

      如果兩個函數做同一件事，卻有著不同的簽名，則這兩個類屬于異曲同工類。應該根據它們的用途重新命名，并進行必要的劃分。

17、過多的注釋

      對應糟糕的代碼，不應以大量的注釋來彌補。

18、在方法體內，如果該方法有參數，強烈建議對參數的有效性和合法性進行檢驗，以避免類型空指針異常等低級BUG。

19、建議在BEAN方法內重寫toString()方法，以提供更好的對象信息展示。