正確理解Java代碼編寫規范

本文從Java代碼編寫的初期到結尾，做了一次整體的總結，希望對初學者有幫助。

1、命名很重要

一個錯誤的命名會很誤導人，不良的命名，對于閱讀代碼的人來說很糾結。一個良好的命名對自己也有很大的幫助。

我個人命名的變量都比較長，一般是單詞的全稱，這樣代碼讀起來易懂，有些縮寫你根本不知道它代表的單詞是什么，除了像id代表identifier，org代表organization這些大家常見的縮寫命名。

命名一個方法時候，最好能讓大家見名知意，看到名字就能猜出你的功能，而不需要去看方法的注釋，甚至是讀源碼來了解你的功能。

2、注釋很重要

寫一個方法時可以先把這個方法的功能、算法原理交代一下，以后自己或者是其他人維護你的代碼時候可以很方便，對于易出錯的部分加注釋提醒。

3、用class類型

寫方法的時候的參數，少用基本類型的組合，而用class類型

比如寫一個查找用戶的方法queryUser(int age)

最開始的業務需求是根據年齡來查找用戶，后來業務規則發生了變化，你可能需要根據年齡和性別來查找用戶，于是你又改成了這樣queryUser(int age, intsex)，假設用0代表男，1代表女(其實更好的實現是用枚舉來表示男女)；

說不定你哪天的業務又變化了，需要根據年齡、性別、家庭住址來查詢，于是乎你又改成了這樣queryUser(int age, int sex, String address)。

如果你當時設計的方法是：queryUser(User user)傳入的參數是一個User類呢，那該多好啊，你根本不需要改接口。

在實際項目開發中改一個接口的成本還是挺大的，實際項目開發中為了達到層次清晰、解耦的目的，后臺分了好多層，action、business、dao其中dao還有分了dao接口和實現，一個接口修改得牽動多少地方。

而當初設計的接口傳遞的是User對象，那么你的代碼可以簡單的增加幾行就能達到了目的，而不需要修改那么多的接口，一邊修改一邊糾結。

4、少復制、粘貼代碼

同樣的代碼不要粘來粘去，當時寫的時候確實是快了，可是以后需要修改的時候可就慢多了。

更可怕的是你要修改多處，結果你只修改了一處，而你自己卻以為萬事大吉了，說不定哪天就蹦出個bug來。應該把這些公共的代碼提取成一個class或者是一個方法。

5、一個方法中不要寫太多的代碼

一個方法中寫好多代碼，寫的時候確實是很方便，很快，更好的辦法是把一個大的方法分解成幾個小的方法，然后在主方法中調用其他子方法。

如果把所有的邏輯都寫在一個方法中，當需求發生變化的時候，再要修改那就慢多了。

我自己寫代碼的時候，剛開始寫某個功能的時候很慢，有幾種實現很糾結到底用那種實現，思考半天，給個變量起個名兒也得半天，有時候還不知道對應的英文單詞，好吧，再打開桌面詞典，查查單詞。

寫個方法時也得糾結半天，先想好方法的名字，然后是參數，還有返回值。

一小段邏輯的代碼可以提取出一個private方法，然后在一個方法中調用好幾個私有的小方法。

這樣讀代碼的人讀起來也輕松，日后需求發生變化了，你的這些個小的邏輯代碼塊兒只要重新組合下，就又能滿足新的功能，可以復用。

我自己寫一個新功能的時候，第一次寫很慢，如果是這個新功能發生了變化，需要修改代碼，修改起來非常快，許多代碼塊兒都是現成的，只需要重新組合一下方法的調用即可。

6、添加設計文檔

增加一個新的功能模塊時最好有個設計文檔，先把方方面面都考慮周全了，設計好了再編碼實現。

如果一開始就有個設計文檔，能把方方面面都考慮周全，實現起來就容易多了，實現的代碼還能優雅些。

為了達到最終的目的，可能中間要走些彎路，如果增加的功能多了，每次實現都走一些彎路，系統最終會變的臃腫不堪。

如果推倒重來，以前的功夫就都白費了，不光是編碼，還有測試部門的測試，有時時間也不允許重構，再說了重構還有風險，這其中的代價還是挺大的。

所以新增功能一定要把需求搞清除，有個良好的設計文檔，考慮周全了再編碼實現。

最后在向SVN提交代碼時先做個功能測試，然后沒問題了，再做個codereview。