代碼整潔之道

有意義的命名

1.名副其實

一旦發現更好的名稱，就換掉舊的。變量、函數或類的名稱應該已經答覆了全部的大問題。它該告訴你，它爲何會存在，它作什麼事，應該怎麼用。若是名稱須要註釋來補充，那就不算是名副其實。

2.避免誤導

3.作有意義的區分

廢話都是冗餘。variable一詞永遠不該當出如今變量名中。NameString會比Name好嗎？

要區分名稱，就以讀者能鑑別不一樣之處的方式來區分。

4.使用讀的出來的名稱

例如，modificationTimestamp要優於modymdhms.

5.使用可搜索的名稱

單字母名稱和數字難以搜索。竊覺得單字母名稱僅用於短方法中的本地變量。若變量或常量可能在代碼中多處使用，則應賦予其便於搜索的名稱。

6.避免使用編碼

把類型或做用域編進名稱裏面，徒然增長了解碼的負擔。

例如IShapeFactory、m_dsc...

7.避免思惟映射

明確是王道。善用其能，編寫其餘人能理解的代碼。

8.類名

名詞或名詞短語，不該當是動詞。

9.方法名

動詞或動詞短語。

10.別扮可愛

寧肯明確，勿爲好玩。言到意到，意到言到。

11.每一個概念對應一個詞

給每一個抽象概念選一個詞，而且一以貫之。

12.別用雙關語

避免將同一單詞用於不一樣目的。代碼做者應盡力寫出易於理解的代碼。

13.使用解決方案領域名稱

儘可能減小依據所涉領域來命名。程序員要作太多技術性工做。給這些事取個技術性的名稱一般是最靠譜的作法。

14.使用所涉問題領域的名稱

若是不能用程序員熟悉的術語來給手頭的工做命名，就採用所涉及問題領域而來的名稱。

優秀的程序員和設計師，其工做之一就是分離解決方案領域和問題領域的概念。

15.添加有意義的語境

用良好命名的類、函數或者名稱空間來放置名稱，給讀者提供語境。若是沒這麼作，給名稱添加前綴就是最後一招了。

16.不要添加沒用的語境

17.最後的話

取好名的最難之處在於須要良好的描述技巧和共有文化背景

函數

函數是全部程序中的第一組代碼。

1.短小

函數的第一規則是要短小。

2.只作一件事

函數應該作一件事。作好這件事。只作這一件事。

若是函數只是作了該函數名下同一抽象層上的步驟，則函數仍是隻作了一件事。編寫函數畢竟是爲了把大一些的概念（換言之，函數的名稱）拆分爲另外一抽象層上的一系列步驟。

3.每一個函數一個抽象層級

函數中混雜不一樣抽象層級，每每讓人迷惑。

自頂向下讀代碼：向下規則。程序就像段落，每一段都描述當前抽象層級，並引用位於下一抽象層級的後續段落。

4.switch語句

確保每一個switch都埋藏在較低的抽象層次，並且永遠不重複，在系統其餘部分看不到。

5.使用描述性的名稱

函數越短小，功能越集中，就越便於取個好名字。

長而具備描述性的名稱。

若是每一個例程都讓你感到深合己意，那就是整潔代碼。

6.函數參數

參數儘量少。參數和函數名處在不一樣的抽象層級，它要求你瞭解目前並不特別重要的細節。

• 輸入參數過多，難以測試。
• 不太指望信息經過輸出參數輸出。
• 避免使用標誌參數（boolean），代表該函數不止作一件事。
• 儘可能使用一些機制將二元函數轉換成一元函數。
• 兩個以上的參數考慮封裝成類，不是在做弊，封裝性和某個概念的考慮。
• 動詞與關鍵詞，要較好解釋函數的意圖，以及參數的順序和意圖。

7.無反作用

實際仍是保持函數只作一件事。有時具備隱藏的破壞性，對類中的變量作出未能預期的改動，致使古怪的時序性耦合及順序依賴等等。

廣泛而言，應避免使用輸出參數。若是函數必需要修改某種狀態，就修改所屬對象的狀態。

8.分隔開指令與詢問

函數要麼作什麼事，要麼回答什麼事，兩者不可兼得，避免混淆。

9.使用異常替代返回錯誤碼

使得錯誤處理代碼從主路徑代碼中分離出來，獲得簡化。

最好把try和catch代碼塊的主體部分抽離出來，另外造成函數。（錯誤處理就是一件事，函數應該只作一件事）

避免依賴磁鐵。

10.別重複本身

重複多是軟件中一切邪惡的根源。許多原則與實踐規則都是爲控制與消除重複而建立。

11.結構化編程

每一個函數、函數中的每一個代碼塊都應該有一個入口、一個出口（結構化編程規範）。只要函數保持短小，偶爾出現的return、break等沒有壞處。

小結

編程藝術是且一直就是語言設計的藝術，函數是語言的動詞，類是名詞。永遠別忘記，真正的目標在於講述系統的故事，而你編寫的函數必須乾淨利落的拼裝在一塊兒，造成一種精確而清晰的語言，幫助你講故事。