2014年 代碼總結與疑問（二）

    緊接上一篇博客 http://my.oschina.net/heweipo/blog/371633 ，對提出的六大問題中部分作一個總結，固然首先要感謝各位好友的熱心評論，尤爲是 關紅福 、xia-yongsheng、甩蔥哥以及蛙牛等人的回覆，是他們讓這篇博客顯得更有意義。

    言歸正傳，下面就對這幾個問題作一個總結，若是還有更好的建議，能夠提出，本人學習的道路上感激涕零。

  問題一：

    關於if語句的使用，有嵌套if，有單分支if...

    有的人說只要註釋清楚if嵌套也是合理的；有的人說三層嵌套之內是能夠接受的；還有的人說採用反轉式的防護式編程，這也是我最贊同的方式，以下：

if(xxx){
return;
}
if(xxx){
return;
}
if(xxx){
return;
}

先一層一層判斷不符合條件的直接退出，那麼剩下的就是能夠正常執行的邏輯了，正好和你嵌套的邏輯判斷是相反的，這樣會更清晰一些。————————@關紅福

if+return的方式確實不錯，儘管return會在代碼中影響代碼可讀性，可是比起else仍是要好不少，另外使用單分支if語句判斷必需要準確，由於不是全部if判斷就能return的。因此，若是有必要請拋棄這種方式吧：

if(){
 
}else if(){
    if(){
     
    }else{
     
    }
}else{
 
}

問題二：

    關於Exception的捕獲與拋出

    對於異常，你們褒貶不一。項目經理用他多年的經驗告訴我：自定義異常那是自討苦吃。其實之前是很流行這種寫法的，由於異常的層層拋出能夠到最上層捕獲，而後能夠合理的處理。但是我看咱們項目裏確實對自定義異常嗤之以鼻。那麼異常具體應該如何處理呢？

「關於異常，一些異常若是不影響接下來的業務邏輯，能夠本身捕捉了，本身處理。不然的話仍是應該拋出異常」

——@蛙牛

那麼，在項目中對異常就須要進行合理分類，哪些異常是影響業務邏輯繼續執行的，哪些是能夠捕獲置之不理的。另外，項目中尤爲忌諱使用一個具體的try-catch捕獲Exception，緣由是，不是對全部異常一視同仁，遇到某些異常咱們應該中止運行。

問題三：

    參數的校驗

    參數校驗問題，我最贊同的是這個觀點：

」每一層本身都要作 *本身的* 校驗。第一是要校驗，第二是本身的不要提早替下一層作校驗。「——@xia-yongsheng

參數校驗是必然的，每一個方法都應該作本身的合理校驗，由於你不敢保證別人調用你時是否作過合理性校驗，那麼本身要對本身負責。有的人以爲只要約定好在某一層作好校驗就能夠，這個我是以爲不妥的，如今不少人都採用maven，每一層均可是一個獨立的項目，請記住它是一個獨立的項目，任什麼時候候均可能被任何人使用。因此，我最贊同的是每一個方法中須要合理校驗,調用別人時不須要提早校驗。

 問題四：

    JSONObject的使用

    這個問題不多有人回答，那麼仍是繼續留着，我也不是很懂，至於Gson的使用，我也是很推薦的，可是咱們項目中不多使用Gson.

 問題五：

    JavaBean的使用

    對於JavaBean貌似沒有什麼滿意的答案，那就說說咱們項目中如何使用的吧，咱們項目中堅定擯棄這種JavaBean，只要是JavaBean的地方均可以採用Map<String,Object>替代，尤爲是對於結果集的封裝，咱們採用List<Map<String,Object>;我記得我開始的時候使用JavaBean，那時候是用JSF+Mybatis編程，從頭至尾都是JavaBean，結果發現若是用JavaBean作查詢參數的話限制太大，我的推薦Map.

 問題六：

    JavaScript中方法參數定義問題

    對於這個問題，不少人都提倡以下作法，那麼我也會學習以下方式，給編碼一個規範，那麼效率天然會提升。

」在對象型的參數不少的狀況下，是頗有用的，通常三個參數之內不須要這樣。這個事情按需求而定。比較明顯的例子能夠參閱jQuery.ajax()。「——@甩蔥哥

最後：

    走過2014，期待2015，但願咱們的代碼更規範、更健壯！謝謝各位了！