代碼大全精粹——個人整理版本目錄設計編碼質量優化設計設計關鍵點1.封裝——信息隱藏類或模塊，只提供合適的接口，并保持不變。實現細節和成員不要暴露給外界即其他模塊。反例：

pDomain=&(g_AAADomain[DomainID]);if(READY==pDomain->Status){…}正例：if(DomainIsReady(DomainID)){…}設計關鍵點封轉的好處：a.降低耦合。尤其是大模塊之間。b.降低復雜度。修改和閱讀代碼時，一個時刻只用關心一層的設計，不用在龐大的代碼中左支右絀。c.屏蔽變化源。例如某數據索引表從Hash表改成AVL樹，不應對外部產生影響，封裝可實現這種屏蔽。Notice：

封裝不僅應該用在大模塊上，也應該用在模塊內的各子模塊上。C語言中不希望被外部調用的函數，可通過函數名前加static前綴來實現信息隱藏設計關鍵點設計關鍵點2.隔離容易改變的區域找出明顯容易變化的功能，將之分離出來成獨立模塊。設計良好接口，使變化不影響模塊外部。容易變化的地方：a.業務規則。例如電話費、上網費的收費模式、費率等。b.硬件依賴性c.困難的設計區域和實現區域。因為這些設計和代碼不是很好，可能需要重新做。隔離使之對系統影響最低。舉例：請教練結合自己項目舉例設計關鍵點3.抽象抽象是從眾多的事物中抽取出共同的、本質性的特征，而舍棄其非本質的特征。抽象本身很“抽象”，不太容易理解。我們來通過軟件實例理解：C++項目中的抽象類C項目中的通用算法庫，例如Hash，就是抽象出了Hash算法的本質，而把具體的“雜湊函數”留給使用者注冊。請教練結合自己項目舉例設計關鍵點抽象的好處：關注高層規則，忽略無關細節，降低軟件復雜度寫出高復用性代碼更好的軟件層次結構Notice：

抽象與語言無關，C語言同樣可實現抽象。編碼子程序和變量名子程序長度

無標準。但超過200行請小心，一般只有復雜算法（如AVL樹，加密等）才會寫出長函數，其余情況出現長函數則要反省設計、分層是否合理。一個子程序只在自己的抽象層次上做一件事情。如果一個子程序的名字無法完全描述它做的事，就違背了這一原則。子程序和變量的名字：

總原則是讓代碼讀起來就跟自然語言一樣流暢。例如if(NameIsValid(userName)){

RemoveAllSpace(userName)…}子程序和變量名過程性子程序起強烈的“動詞+賓語”的名字，例如RemoveAllSpace()等。邏輯判斷子程序，名字寫為肯定語句。

面向對象例子：boolCLASS_USER_NAME::IsValidName();C語言例子：BOOLNameIsValid(&userName);

使用時就是如下流暢的語句：if(userName.IsValidName())或if(!userName.IsValidName())if(NameIsValid(&userName))語句1.循環循環變量使用有意義的變量名，避免習慣性使用i,j,k反例：for(i=0;i<MAX_USER_ID;i++){for(j=0;j<MAX_PAYOUT_TYPE;i++){sum+=employee[i].payout[j];}}正例for(userID=0;userID<MAX_USER_ID;userID++){for(payType=0;payType<MAX_PAYOUT_TYPE;payType++){sum+=employee[userID].payout[payType];}}好處：提高可讀性避免i,j,k寫代碼手誤設計關鍵點語句2.判斷語句判斷語句盡量寫為肯定形式，少用==判斷反例：if(TRUE==procResult){….}正例：if(procSuccess){….}好處：接近自然語言，提高可讀性；避免==手誤為=設計關鍵點語句語句3.克服深層嵌套一份研究表明，很少有人能理解超過三層的嵌套。當寫出深層嵌套時，如何改進？方法一：重新梳理判斷邏輯，重新設計被嵌套的代碼。某些情況下深層嵌套是混亂思路的產物。方法二：把深層嵌套的代碼提取出來放進單獨的子程序。只要提取的代碼是一個完整、獨立的概念。注釋1.盡量寫出“自說明代碼”盡量讓代碼像自然語言一樣流暢，即使不用注釋也能輕松看懂。通過好的子程序名、變量名、良好邏輯分層、清晰布局、低復雜度的控制流程和數據結構等實現該目標。2.注釋只允許有如下三類：1）概述性注釋。說明某一段代碼的總體意思。例如一個子程序中，各功能段的概述說明。2）目的性注釋。說明一段代碼的意圖，要解決的問題，而非解決的方法。例如函數頭的函數功能說明3）說明代碼無法表述的信息。例如與設計有關的注意事項，優化標記等。其他類型的注釋，要么是無用的，重復說明代碼本身已經明白無誤的內容；要么說明代碼本身含糊不清，必須要另外說明，這種情況下最好改進代碼。

這是理想情況。在現有代碼無法達到自說明的情況下，還是要將理解有困難的地方都進行注釋。注釋質量優化降低程序復雜度1.什么是程序復雜度程序復雜度的一個標準：為了理解應用程序，你必須在同一時間記住的智力實體的數量直觀標準：理解程序所需要花費的精力。復雜度代表什么？復雜度與程序可靠性成反比，與程序錯誤率成正比。復雜度高的代碼可讀性差，難以理解2.如何度量復雜度TomMcCabe方法：通過子程序中“決策點”來數量衡量復雜度。1.從1開始，一直往下通過程序2.一旦遇到以下關鍵字，或者其同類的詞，就加1：if,while,repeat,for,and,or3.給case語句中的每一種情況都加1例子：如下子程序復雜度為多少？

int

firstNum(inta,intc){for(b=0;b<MAX_NUM;b++){if(a<b&&b<c){returnb;}}}降低程序復雜度4降低程序復雜度3.如何處理復雜度度量結果0-5子程序可能還不錯6-10得想辦法簡化子程序10+把子程序的某一部分拆分成另一個子程序并調用它把子程序的一部分提取成另一個子程序，不會降低整個程序的復雜度，只是把決策點移到其他地方。但這樣可以降低你在同一時間必須關注的復雜度水平。有時混亂的代碼是混亂思維的產物，這種情況需要重新整理出清晰的函數邏輯。（這條是我個人的總結）10的上限不是絕對，只是一個警示。有些情況下子程序高復雜度不可避免。開發者測試1.什么是開發者測試完整測試過程：單元測試、組件測試、集成測試、回歸測試、系統測試。開發者測試主要指前三項：單元測試：類或子程序測試組件測試：也就是我們的模塊測試集成測試：多模塊的聯合測試2.推薦的測試項對每一項相關需求進行測試對每一個相關設計關注點進行測試典型數據、邊界數據、錯誤數據測試舉例：四則運算程序，請大家給出測試項。開發者測試3.推薦的測試方法測試先行保留測試用例，用于后續重新測試（回歸測試）自動化測試，使測試可快速、頻繁進行。例如測試用例函數中使用Assert判斷結果，而非打印出來肉眼觀察。開發者測試重構重構的定義：在不改變軟件外部行為的前提下，對其內部結構進行改變，使之更容易理解并便于修改。問題：何處需要重構，怎么重構？1.何處需要重構，怎么重構這里只說明幾種常見類型重復。代碼重復、結構重復、邏輯重復。重復的代碼是抽象不夠的表現。如果是一個獨立完整的概念，可以提取成一個子程序（抽象）。舉例：多處的排序算法。冗長子程序。如果把子程序的一部分提取來作為另一個獨立的子程序，可以讓代碼更清晰，就提取成子程序。循環過長或嵌套過深。循環內部的復雜代碼往往可以轉換成子程序。嵌套過深可以用前面“語句”中提過的方法解決。子程序命名不當。需要子程序重命名，或合并、拆分子程序。難懂、拙劣的代碼。需要重整邏輯和流程。問題：何時進行重構？重構2.重構的時機開發時，不斷重構。在開發階段，每完成一個小功能點、或修補一個缺陷時，都應該審視是否有需要重構的地方，保證持續集成中代碼不腐化。維護時，因故障或需求變化而修改某功能時，對修改到的代碼進行重構。但注意只能重構修改的地方！不能在解決故障時重構與之無關的代碼！問題：如何保證重構安全？這可能是阻礙我們進行重構的最大因素！重構3.如何保證重構安全重構前保存初始代碼，保證重構失敗可以返回。重構的步伐要小。盡量一次只處理一項重構，除非是最為簡單的重構。重新測試（回歸測試）。開發者自測階段請保留測試用例，最好是自動化測試用例，可以迅速重新測試，看重構后的代碼能否通過之前的測試用例。重構性能優化1.性能優化誤區隨時隨地進行優化

為微觀的最終效果不足道的優化，可能浪費了大量的時間，而對整個系統全局性的重要優化視而不見。同時也為了微弱的性能提升而犧牲了正確性、可讀性等其他重要的軟件質量。優化=修改代碼

遍歷查找數據的代碼，再怎么修改優化，也不可能超越Hash查找算法、AVL樹查找算法——優化需要先從更高層的需求、設計做起！2.什么是真正的優化按如下的優先順序來思考提高性能：需求設計程序同操作系統交互代碼編譯硬件代碼調整首先從需求、設計、編譯器優化等級、硬件等上面提高效率，可以更全局、簡單、安全、高效地提高效率。最后才是考慮代碼