正確理解Java代碼編寫規(guī)范

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

1、命名很重要

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

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

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

2、注釋很重要

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

3、用class類型

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

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

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

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

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

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

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

4、少復(fù)制、粘貼代碼

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

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

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

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

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

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

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

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

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

我自己寫一個新功能的時候，第一次寫很慢，如果是這個新功能發(fā)生了變化，需要修改代碼，修改起來非?？欤S多代碼塊兒都是現(xiàn)成的，只需要重新組合一下方法的調(diào)用即可。

6、添加設(shè)計文檔

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

如果一開始就有個設(shè)計文檔，能把方方面面都考慮周全，實現(xiàn)起來就容易多了，實現(xiàn)的代碼還能優(yōu)雅些。

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

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

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

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