CleanCode代碼規範

Clean Code代碼規範

一、有意義的命名

1.一、名副其實

知道函數發生了什麼，傳入什麼，返回什麼

1.二、避免誤導

避免留下隱藏代碼本意的錯誤線索

1.三、作有意義的區分

廢話是另一種沒有意義的區分

1.四、使用讀得出來的名稱

讀起來像人話

1.五、使用可搜索的名稱

二、類名

2.一、類名和對象名應該是名詞或者名詞短語

如Customer 、WikiPage、 AddressParser,避免使用Manager、 Processor 、Data 、Info 模糊的類名，也不該當是動詞。

三、方法名

3.一、應該是動詞或者動詞短語

3.二、屬性訪問、修改器和斷言

依Javabean標準加get、set和is前綴 如employee.getName(), .setName("mike");,.isPosted()

3.三、重載構造器，使用描述了參數的靜態工廠方法。

Complex fulcrumPoint = Complex.FromRealNumber(23.0)好於new的方式，構造器設爲private，強制使用（多種）

3.四、別用雙關語

避免將統一律念用於不一樣的目的，統一術語用於不一樣概念。代碼做者儘可能寫出讓別人易於理解的代碼，一目盡覽，而沒必要讓人殫精竭慮研究。正例：add 、append 、insert。

3.五、使用解決方案領域名稱，如設計模式相關命名

3.六、集中精力於把代碼寫得就像詞句篇章（可讀性）

四、避免使用編碼，避免思惟映射

4.一、 java不須要變量類型編碼（匈牙利語標記法）

對象是強類型的，編輯環境已經能夠解決類型錯誤

4.二、成員前綴--沒必要用m_表示成員前綴

應使用某種高亮或者顏色標識出成員的環境

4.三、接口和實現--不建議加接口標示I或者Interface

加實現Imp後綴好於前者，或者也能夠不加

4.四、避免思惟映射-變量名稱明確是王道！

專業程序員善用其能，編寫其餘人能讀懂的代碼。

五、函數

5.一、短小 < 15行

函數的第一規則是短小，第二規則是更短小。每一個函數都只說一件事，每一個函數都一目瞭然。每一個函數都依序把你帶到下一個函數。15行？

5.二、代碼塊和縮進（不超過三層）

if else while語句等，其中的代碼塊應該只有一行，即函數調用語句，以保持函數短小

函數的縮進級不該該多於三層

5.三、只作一件事

函數應該只作一件事，作好這件事。只作這一件事。判斷函數是否不止作了一件事的方法，看是否能再抽出一個函數。函數中若是存在多個區段，代表函數作的事情不止一件。

5.四、每一個函數一個抽像層級

每一個函數一個抽像層級。確保函數只作一件事，函數中全部的語句都在一個抽象層級上。函數中混雜不一樣抽象層級，每每讓人迷惑，更惡劣的是，就像破損的窗戶，一旦細節與基礎概念混雜，更多的細節就會在函數中糾結起來

5.五、自頂向下閱讀代碼：向下規則

讓每一個函數後面都跟着位於下一抽象層級的函數，在查看函數列表時，就能依抽象層級向下閱讀。

5.六、確保每一個switch都埋藏在較低的抽象層級，並且永遠不重複

5.七、使用描述性的名稱

使用描述性的名稱：函數越短小，功能越集中，就越便於取個好名字

長而具備描述性的名稱，比短而使人費解的名稱好。長而具備描述性的名稱，要比描述性的長註釋好。讓函數名稱中的多個單詞容易閱讀，而後使用這些單詞給函數取個能說清其功用的名稱。別懼怕花時間取名字，嘗試不一樣的名稱，實測閱讀效果。選擇描述性的名稱能理清你關於模塊的設計思路，並幫你改進。追索好名稱，每每致使對代碼的改善重構。命名方式要保持一致。使用與模塊名一脈相承的短語、名詞和動詞給函數命名。使用相似措辭，依序講出一個故事。

5.八、函數參數，最好沒有，儘可能避免三個

足夠特殊理由才能用三個以上參數。從測試角度看，參數更叫人爲難。

5.九、標識參數 ，這是標識函數不止作一件事情的明確信號，應該拆分。

5.十、二元函數，儘可能改寫爲一元函數

利用一些機制將其轉換爲一元函數。（多個參數封裝成臨時類，不是一個好的解決方式）

5.十一、函數和參數應當造成一種很是良好的動/、名詞對形式

如assertEqual 改爲assertExpectedEqualsActual（expected，actual）大大減輕記憶參數順序的負擔。

5.12避免使用輸出參數

若是函數必需要修改某種狀態，就修改所屬對象的狀態。

5.1三、分隔指令與詢問

函數要麼作什麼事 要麼回答什麼事，但兩者不可得兼。

函數應該修改某對象的狀態，或是返回該對象的有關信息。兩樣都幹常會致使混亂。

5.1四、使用異常替代返回錯誤碼。

從指令式函數返回錯誤碼輕微違反了指令與詢問分隔的規則。鼓勵了在if語句判斷中把指令當作表達式使用。另外一方面，若是使用異常替代返回錯誤碼，錯誤處理代碼就能從主路徑徑代碼中分離出來，獲得簡化。

5.1五、抽離Try/Catch代碼塊。

Try/Catch代碼醜陋不堪。他們搞亂了代碼結構，把錯誤處理與正常流程混爲一談。把try和catch代碼塊的主體部分抽離出來，另外造成函數。

函數應該只作一件事。錯誤處理就是一件事。所以，處理錯誤的函數不該該作其餘的事，若是關鍵字try在某個函數中存在，它就應該是這個函數的第一個單詞，並且在catch/fianlly代碼塊後面也不該該有其餘內容。

5.1六、別重複本身

重複多是軟件中一切邪惡的根源。許多原則與實踐規則都是爲控制與消除重複而建立。如面向對象將代碼集中到積累，避免冗餘。

5.1七、如何寫出好的函數

寫代碼和寫別的東西很像，在寫論文或者文章時，你先想什麼就寫什麼，而後再打磨它。初稿也許粗陋無序，你就斟酌推敲，直至達到你心目中的樣子。

我寫函數時，一開始都冗長而複雜。有太多縮進和嵌套循環。有過長的參數列表。名稱時隨意取的，也會有重複的代碼。不過我會配上一套單元測試，覆蓋每行醜陋的代碼。 而後我打磨這些代碼，分解函數、修更名稱、消除重複。我縮短和從新安置方法。有時我還拆散類。同時保持測試經過。

最後，遵循本章列出的規則，我組裝好這些函數。我並不從一開始就按照規則寫函數。我想沒人作獲得。

5.1七、小結

每一個系統都是使用某種領域特定語言搭建，而這種語言是程序員設計來描述那個系統的。

函數是語言的動詞（描述具體作了什麼事），類是名詞。這並不是是退回到那種認爲需求文檔中的名詞和動詞就是系統中類和函數的最初設想的可怕的舊觀念。其實，這是個歷史悠久的真理。編程藝術是是且一直是一門語言設計的藝術。大師級程序員把系統當作故事來說，而不是當作程序來寫。他們試用選定編程語言提供的工具構建一種更爲豐富且更具表達力的語言，用來說那個故事。那種領域特定語言的一個部分，就是描述在系統中發生的各類行爲的函數層級。在一種狡猾的遞歸操做中，這些行爲適用他們定義的與領域緊密相關的語言講述本身那個小故事。

本章所講述的是有關編寫良好函數的機制。若是你遵循這些規則，函數就會短小，有個好名字並且被很好低歸置。不過永遠別忘記，真正的目標在於講述系統的故事，而你編寫的函數必須乾淨利落地拼裝到一塊兒，造成一種精確而清晰的語言，幫助你講故事。

六、代碼佈局

6.一、垂直原則

6.1.1 歸組

若是代碼屬於如下情形，代碼應歸於一組，組之間用空行分隔

1.實現同一功能的
 2.執行同類任務的（錯誤處理等）
 3.屬性相同的（變量類型等）
 4.有相互調用關係的

6.1.2 單個文件垂直大小不超過500行（<5%）

6.二、水平原則：

6.2.一、單行代碼中，要準確的使用空格，

1.賦值操做符周圍加空格
 2.參數間逗號後加空格
 3.優先級低的運算符與先後項加空格
 4.優先級高的運算符與先後項不加空格
 5.函數名和參數之間不加空格

6.2.二、代碼塊中，遇到新的繼承結構要縮進

6.2.三、單行代碼水平寬度不超過80字符

七、 註釋

7.一、寫註釋前，先仔細考慮是否能夠優化代碼的描述方式

7.二、 註釋和代碼是應是同步的

7.三、 註釋是意義明確的，不須要自解釋

7.四、註釋只說明代碼爲何這樣寫，而非怎樣寫

7.五、警告、版權協議、公共API是必需寫的註釋

http://210.21.236.159/cleanCo...