如何編寫簡潔的代碼？

時間 2019-11-07

標籤如何編寫簡潔代碼简体版

原文原文鏈接

引言

學習來源：《Clean Code》 [美] Robert C.Martin。
程序員

這是本人的學習筆記，如今大部分寫代碼的時候已經對這些規則和概念有了一個清晰的認識，但願你們有機會也能看一看《Clean Code》這本書，總結出屬於本身須要的規則。算法

一.有意義的命名

1.名副其實

int d;//消逝的時間,以日計
int elapsedTimeInDays;
複製代碼

2.避免誤導

別用accountList來指稱一組帳號，除非它真的是List類型。提防使用不一樣之處較小的名稱。誤導性名稱最可怕的例子，是用小寫字母「l」和大寫字母「O」做爲變量名。由於他們看起來實在太像數字「零」和「壹」。如如下代碼：

int a=l;
if(O==l)
  a=O1;
else
 l=01;複製代碼

3.作有意義的區分

廢話是另外一種沒意義的區分。例如你有一個Product類和一個ProductInfo類,這兩個名稱雖然不一樣,意思卻毫無區別。

4.使用讀的出來的名稱

像生成時間戳這個變量應該是 generationTimestamp 而不是 genymdhms .
編程

5.使用可搜索的名稱

儘可能避免使用單字母和數字做爲常量名稱，由於它們一般很難在一大段代碼中被準確的搜索出來。做者認爲單字母名稱僅用於短方法中的本地變量。名稱長短應與其做用域大小相對應。
bash

6.避免使用編碼

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

匈牙利語標記法
成員前綴（不必使用前綴來標明成員變量，應當把類和函數作的足夠小，消除對成員前綴的須要）以下代碼：

public class Part{
  String description;
  void setDescription(String description){
    this.description=description;
  }
}複製代碼

7.避免思惟映射

不要讓讀者在腦中把你的名稱翻譯爲他們熟知的名稱。這種問題常常出如今選擇是使用問題領域術語仍是解決方案術語時。
函數

8.類名

類名應該是名詞或名詞短語，例如 Customer、WikiPage、Account 和 AddressParser，避免使用 Manager、Processor、Data或者Info這樣的類名。

類名不該當是動詞。post

9.方法名

方法名應當是動詞或動詞短語，如 postPayment、deletePage 或save。

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

給每一個抽象概念選一個詞，而且一以貫之。例如，使用fetch、retrieve和 get 來給在多個類中的同種方法命名。
學習

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

記住，只有程序員纔會讀你的代碼。因此，儘管使用那些計算機科學術語、算法名、模式名、數學術語吧。依據問題所涉領域來命名可不算是聰明的作法。
fetch

12.使用源自所涉問題領域的名稱

若是不能使用解決方案領域名稱來命名，就採用所涉問題領域的名稱，至少負責維護代碼的程序員能夠去請教該領域專家。
優化

13.添加有意義的語境

讓你的代碼讀起來是連貫的，是在同一語境的。能明確的知道，這些類，函數是某個結構的一部分。這須要經過良好命名的類，函數和命名空間來造成有意義的語境。
ui

14.不要添加沒用的語境

只要短名稱足夠清楚，就比長名稱好，不要一昧的追求長名稱，從而形成不少沒必要要的語境。給人以困擾。

二.函數

1.第一規則：短小

if語句、else語句、while語句等，其中的代碼塊應該只有一行。函數的縮進層級不該該多於一層或兩層。

2.只作一件事

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

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

自頂向下讀代碼：向下原則。

4.使用描述性的名稱

長而具備描述性的名稱，要比短而使人費解的名稱好。

長而具備描述性的名稱，要比描述性的長註釋好。

5.函數參數

參數數量儘量的少，最好的是零參數函數，其次是一（單參數函數），再次是二（雙參數函數），應儘可能避免三（三參數函數）。

5.1 標識參數

應當儘可能避免標識參數，避免向函數傳入布爾值。

5.2 三元函數

寫三元函數以前必定要深思熟慮，是否有必須寫三個參數的必要性。

5.3 參數對象

若是函數須要兩個，三個或三個以上的參數，就說明其中一些參數應該封裝爲類了。

5.4 動詞與關鍵字

對於一元函數，函數和參數應當造成一種很是良好的動詞/名詞對形式。

例如：write(name),或者更好的名稱：writeField(name)。
例如：assertEqual改爲assertExpectedEqualsActual(expected,actual)。
複製代碼

5.5 錯誤處理

使用異常代替返回錯誤碼
抽離Try / Catch 代碼塊
函數應該只作一件事，錯誤處理就是一件事。所以，錯誤處理的函數不應作其餘事。

5.6 別重複本身

不要編寫重複性的函數。

5.7 結構化編程

Edsger Dijkstra的結構化編程規則。

三.註釋

關於註釋的問題，首先咱們應該明確的是能用代碼闡述的就不要寫註釋，避免誤導。也就是代碼可讀性很是高，幾乎能夠不用註釋，這須要良好的命名習慣來造成。另外，註釋並不可以美化你寫的糟糕的代碼。與其有時間寫註釋，不如花時間優化你的代碼。若是咱們在必須寫註釋的狀況下，須要明確的知道本身想要寫的是好註釋仍是壞註釋。