如何寫出優美的java程式碼(轉載)
阿新 • • 發佈：2019-01-19
一、不要使用魔法數字，儘量定義列舉、常量、巨集：
我常常見到表示各種狀態的數字，0，1，2....，我真的不知道這表示什麼含義，如果
你在不在文件中說明的話，這個東東過幾天連你自己都不知道個一二三了。
二、命名要具有描述力，儘量使用全名而不是自創的縮寫，除非地球人都這麼用這個縮寫：
我常常看到一些自創的縮寫，這個縮寫或許只有你自己知道，類名，方法名，引數名
尤其要有好的描述裡，區域性變數尚可容忍。我寧可容忍超過40個字元的命令，也不願意
看到只有一兩個字母的命名，當然迭代用的i,j除外。當然命名不要太長，太長說明你的類和
方法要做的事情太多，請你拆分出更多細粒度功能單一的類和方法。
三、同一類東東命名方式儘可能統一，比如類名使用大寫字母開頭的單詞，變數使用
下劃線分割開來的小寫字母單詞，常量使用下滑線分割的開來的大寫字母單詞。不要
交替使用。
四、函式、類功能儘可能單一，不要試圖寫一個萬能/超級函式或者類。
一個類和方法要有單一的職責，這樣的類和方法只做一件事，並且容易把他做好。
1、不要試圖寫一個強大無比的方法。
我常常看到一些試圖寫的多麼“精妙”無比多麼“強大”的函式，事實上不是什麼精妙，而是
程式碼的臭味道。精妙強大無比萬能的方法往往你耗費大量精力去設計演算法，試圖覆蓋現在的各
種可能，而無法面對將來新的需求，隨著新的需求，你的這個精妙的方法需要的修改並且改起來
極其痛苦。在一次次的痛苦與精妙的演化中，你的方法越來越複雜，並且每一次修改你都會面
臨影響以前功能的風險。這個方法使用者需要小心的處理你的精妙之處，如果沒有精妙傳遞好參
數，那麼這個方法再也不精妙了，而是直接廢掉了。
KISS（keep it simple and stupid）原理就是這個道理，你要使你的程式碼儘可能簡單，讓人
看到有一目瞭然的清爽，而不是因為設計了一個精妙無比的萬能方法而沾沾自喜。這裡的簡單不是
簡潔的代名字。有時候簡潔是那種傳說的“精妙”的程式碼。
2、不要寫做多件事情的方法和類，你做一件事情，你就寫一個對應的方法，不要試圖通過引數來判定各種情況，然後做事情，並且做的事情和你方法描述的不一致。當你發現你的方法名字想不出來好的名字了，或者要加or和and了，那麼請你拆分出更多單一的方法。
不要舉一些linux完成多種功能系統呼叫，這是被迫的，因為系統呼叫的數量是有限制的，它只有有限的空間來描述系統呼叫號和系統呼叫的對映表，不要在應用程式開發中效仿而誤以為優雅強大。我最噁心根據引數，然後一大堆的if..else 和switch..case判斷。
五、不要修改已有的類和方法而是擴充套件它。
這是程式設計的一個重要原則，開閉原則，在面向物件的語言中尤為重要。在面向過程中主要表現在，不要在一個函式要應對和這個函式相似的一個需求了，就在這個加個if，來修改這個方法，試圖重用和避免重複。而是要把公用的部分抽出來成一個小的功能函式，然後增加一個應對新的類似這個需求的處理方法。在面向物件中，例如使用策略模式、訪問者模式、Extend Object模式。
六、不要重複你自己（DRY）：
程式最怕的是copy,paste，到處是重複的程式碼。copy，paste經常被誤以為快速完成需要用的功能的高效方式而被到處使用。你每重複一次，你就得負責保持他們的一致性，你就得在一處增加新的功能時，你就的把這個的功能加到其他地方。還在我剛會寫程式碼的時候去了一個小公司，他們的程式碼到處是copy，paste的痕跡，當要在現有的功能增加審計功能是，他們開始下命令了，每個人加幾行程式碼來做審計，真不知道那麼多人寫的審計版本，分散到那麼多處，這個審計功能是否可信有用。
避免DRY的方法就是抽象，分離變化。不管是面向物件還是面向過程，分離變化並抽象之是最主要的設計原則。設計模式中的模板方法，我們常用的回撥都是我們常用的方法。
我發現越是提供更多回調處理的語言和框架，就越具有靈活性和易用性。ruby語言之所以有如此的威力，主要是因為它提供了更多的回撥處理。它可以在動態的給一個類增加方法，這樣可以在超類中定義增加方法的方法，然後再子類呼叫，子類就具有無比的能力。它的block提供了強大的回撥機制，我只要不知道如何處理了我就yield出來，method missing機制更是神祕無比，你可以寫出像find_by_name_and_age,2.days.ago這樣像自然語言一樣易讀的程式碼。
七、不要跨越邊界，在適合的地方寫程式碼。
在分層的架構中，不要跨越層的邊界。例如web開發的三層架構:
資料訪問層（DAO)、業務層(Service)、表現層。
不要在業務層裸寫SQL來做事情，不要在業務層摻和進來表現層的東東，不要在表現層/控制器中寫業務的東東。既然已經分層了，那麼就要好好的遵守它，如果到處跨越邊界的話，那麼和不分層沒有什麼區別，使得每一層都不倫不類。例如你應該在業務層進行事務管理，而你的控制器到處是業務程式碼，那將無法控制。如果你的業務層到處是SQL，我不知道你的DAO存在的意義了。
八、分層的web架構：
DAO層最好按照模型來劃分dao類，如果業務很簡單，也可以將相關的模型合併為一個DAO。
Service層，不要按照DAO和Service一一對應的方式劃分，而是要按照業務的類別和實際情況來劃分。事實上Service層通常是用來處理涉及到多個模型的業務，而涉及到一個模型的業務，常常被放在模型中，這是一種自然而更面向物件的設計方法。只有資料的模型被稱為貧血型模型，這種模型被認為是對面向物件的一種背離，而在模型中放置專有的業務方法，不僅有利於公用，而且模型更具有描述力。
九、關於MVC:
MVC是一種鬆耦合的設計方案，最容易誤用的就是控制器（c）。控制器只負責呼叫業務方法，準備好資料供View去展現。而不要把業務和如何展示的東東放在裡面。我常常看到有人在控制器中拼html片段和寫一些業務相關的程式碼。
十、順便說一下異常的使用。
如果你是使用語言支援異常機制，那麼儘可能的使用異常機制和定義好與自己業務相關的異常，而不是通過返回值表示正確和錯誤。如果你使用的語言支援異常機制，請不要寫類linux下c似的程式碼形式，每寫一個函式，我就寫一個判斷返回值呼叫是否成功，嚴重分離了我對核心業務的關注。異常提供了優雅的處理錯誤的方法。
總之，你在寫程式碼的時候，你儘量考慮使用你介面的人和閱讀你程式碼的人，不要讓他們不爽。
先寫到這裡，希望對大家有所幫助
本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/virgoboy2004/archive/2009/07/30/4394110.aspx
我常常見到表示各種狀態的數字，0，1，2....，我真的不知道這表示什麼含義，如果
你在不在文件中說明的話，這個東東過幾天連你自己都不知道個一二三了。
二、命名要具有描述力，儘量使用全名而不是自創的縮寫，除非地球人都這麼用這個縮寫：
我常常看到一些自創的縮寫，這個縮寫或許只有你自己知道，類名，方法名，引數名
尤其要有好的描述裡，區域性變數尚可容忍。我寧可容忍超過40個字元的命令，也不願意
看到只有一兩個字母的命名，當然迭代用的i,j除外。當然命名不要太長，太長說明你的類和
方法要做的事情太多，請你拆分出更多細粒度功能單一的類和方法。
三、同一類東東命名方式儘可能統一，比如類名使用大寫字母開頭的單詞，變數使用
下劃線分割開來的小寫字母單詞，常量使用下滑線分割的開來的大寫字母單詞。不要
交替使用。
四、函式、類功能儘可能單一，不要試圖寫一個萬能/超級函式或者類。
一個類和方法要有單一的職責，這樣的類和方法只做一件事，並且容易把他做好。
1、不要試圖寫一個強大無比的方法。
我常常看到一些試圖寫的多麼“精妙”無比多麼“強大”的函式，事實上不是什麼精妙，而是
程式碼的臭味道。精妙強大無比萬能的方法往往你耗費大量精力去設計演算法，試圖覆蓋現在的各
種可能，而無法面對將來新的需求，隨著新的需求，你的這個精妙的方法需要的修改並且改起來
極其痛苦。在一次次的痛苦與精妙的演化中，你的方法越來越複雜，並且每一次修改你都會面
臨影響以前功能的風險。這個方法使用者需要小心的處理你的精妙之處，如果沒有精妙傳遞好參
數，那麼這個方法再也不精妙了，而是直接廢掉了。
KISS（keep it simple and stupid）原理就是這個道理，你要使你的程式碼儘可能簡單，讓人
看到有一目瞭然的清爽，而不是因為設計了一個精妙無比的萬能方法而沾沾自喜。這裡的簡單不是
簡潔的代名字。有時候簡潔是那種傳說的“精妙”的程式碼。
2、不要寫做多件事情的方法和類，你做一件事情，你就寫一個對應的方法，不要試圖通過引數來判定各種情況，然後做事情，並且做的事情和你方法描述的不一致。當你發現你的方法名字想不出來好的名字了，或者要加or和and了，那麼請你拆分出更多單一的方法。
不要舉一些linux完成多種功能系統呼叫，這是被迫的，因為系統呼叫的數量是有限制的，它只有有限的空間來描述系統呼叫號和系統呼叫的對映表，不要在應用程式開發中效仿而誤以為優雅強大。我最噁心根據引數，然後一大堆的if..else 和switch..case判斷。
五、不要修改已有的類和方法而是擴充套件它。
這是程式設計的一個重要原則，開閉原則，在面向物件的語言中尤為重要。在面向過程中主要表現在，不要在一個函式要應對和這個函式相似的一個需求了，就在這個加個if，來修改這個方法，試圖重用和避免重複。而是要把公用的部分抽出來成一個小的功能函式，然後增加一個應對新的類似這個需求的處理方法。在面向物件中，例如使用策略模式、訪問者模式、Extend Object模式。
六、不要重複你自己（DRY）：
程式最怕的是copy,paste，到處是重複的程式碼。copy，paste經常被誤以為快速完成需要用的功能的高效方式而被到處使用。你每重複一次，你就得負責保持他們的一致性，你就得在一處增加新的功能時，你就的把這個的功能加到其他地方。還在我剛會寫程式碼的時候去了一個小公司，他們的程式碼到處是copy，paste的痕跡，當要在現有的功能增加審計功能是，他們開始下命令了，每個人加幾行程式碼來做審計，真不知道那麼多人寫的審計版本，分散到那麼多處，這個審計功能是否可信有用。
避免DRY的方法就是抽象，分離變化。不管是面向物件還是面向過程，分離變化並抽象之是最主要的設計原則。設計模式中的模板方法，我們常用的回撥都是我們常用的方法。
我發現越是提供更多回調處理的語言和框架，就越具有靈活性和易用性。ruby語言之所以有如此的威力，主要是因為它提供了更多的回撥處理。它可以在動態的給一個類增加方法，這樣可以在超類中定義增加方法的方法，然後再子類呼叫，子類就具有無比的能力。它的block提供了強大的回撥機制，我只要不知道如何處理了我就yield出來，method missing機制更是神祕無比，你可以寫出像find_by_name_and_age,2.days.ago這樣像自然語言一樣易讀的程式碼。
七、不要跨越邊界，在適合的地方寫程式碼。
在分層的架構中，不要跨越層的邊界。例如web開發的三層架構:
資料訪問層（DAO)、業務層(Service)、表現層。
不要在業務層裸寫SQL來做事情，不要在業務層摻和進來表現層的東東，不要在表現層/控制器中寫業務的東東。既然已經分層了，那麼就要好好的遵守它，如果到處跨越邊界的話，那麼和不分層沒有什麼區別，使得每一層都不倫不類。例如你應該在業務層進行事務管理，而你的控制器到處是業務程式碼，那將無法控制。如果你的業務層到處是SQL，我不知道你的DAO存在的意義了。
八、分層的web架構：
DAO層最好按照模型來劃分dao類，如果業務很簡單，也可以將相關的模型合併為一個DAO。
Service層，不要按照DAO和Service一一對應的方式劃分，而是要按照業務的類別和實際情況來劃分。事實上Service層通常是用來處理涉及到多個模型的業務，而涉及到一個模型的業務，常常被放在模型中，這是一種自然而更面向物件的設計方法。只有資料的模型被稱為貧血型模型，這種模型被認為是對面向物件的一種背離，而在模型中放置專有的業務方法，不僅有利於公用，而且模型更具有描述力。
九、關於MVC:
MVC是一種鬆耦合的設計方案，最容易誤用的就是控制器（c）。控制器只負責呼叫業務方法，準備好資料供View去展現。而不要把業務和如何展示的東東放在裡面。我常常看到有人在控制器中拼html片段和寫一些業務相關的程式碼。
十、順便說一下異常的使用。
如果你是使用語言支援異常機制，那麼儘可能的使用異常機制和定義好與自己業務相關的異常，而不是通過返回值表示正確和錯誤。如果你使用的語言支援異常機制，請不要寫類linux下c似的程式碼形式，每寫一個函式，我就寫一個判斷返回值呼叫是否成功，嚴重分離了我對核心業務的關注。異常提供了優雅的處理錯誤的方法。
總之，你在寫程式碼的時候，你儘量考慮使用你介面的人和閱讀你程式碼的人，不要讓他們不爽。
先寫到這裡，希望對大家有所幫助
本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/virgoboy2004/archive/2009/07/30/4394110.aspx