以下總結一些不好的代碼規范， 借此警示自己不要犯這種錯誤

注釋

1.不恰當的注釋

注釋應該僅用來描述有關代碼和設計的技術性信息。像修改歷史等信息不應出現在注釋中

2.廢棄的注釋

過時、無關或錯誤的注釋就是廢棄的注釋，不要寫這種注釋，如果發現了請盡快更新或刪除，否則它會越來越遠離它開始描述的代碼

3.多余的注釋

如果代碼自身就能說明，就不要去寫注釋，例如：

i++; // i自增

注釋應該說明代碼自身沒有提到的事情。

4.注釋掉的代碼

一般注釋掉的代碼，很可能已經與現有系統無關了，它調用的變量或函數可能已經改名，變得毫無用處

函數和類

1.過多的參數

一個函數的參數個數最好為零，如果有三個以上，可能就要考慮封裝了

2.標識參數

如果函數的參數存在布爾值，只會讓人迷惑，完全可以將其拆分為兩個函數，枚舉也是同樣的道理

3.死函數

沒有被用到的函數，應該盡早刪除

4.死代碼

死代碼就是不會被執行到的代碼，它可能出現在不會觸發的if語句中，或者不會拋出異常的try catch中。如果找到這樣的代碼，請今早刪除。

5.垂直距離

變量應該在首次使用的上面聲明。函數應該放到首次被調用的下面一點點

6.前后不一致

如果在某個地方把響應對象命名為response, 則在其他地方也應該如此命名。如果把某個方法命名為getCommonModule, 則處理相似事情的方法應該取相似的名字，如：getUserModule。這會讓代碼扔易于閱讀和修改。

7.錯誤位置的安放

對于一個函數或常亮的位置，應該放在讀者自然而然期待它出現的地方

8.不恰當的靜態方法

如果一個方法被命名為靜態方法，說明它所需要的變量全部來源與參數，而不是對象的屬性，同時也不會用到多態的特性。

當然有些方法命名為靜態是有必要的，如：Ｍath.max(a,b), 如果還需要　new Math().max(a,b), 也太蠢了

9.不恰當的函數名

如果看到一個函數名之后，仍然對其意圖存在疑惑，甚至還要去查看源碼，那么請換個名字吧。

10.錯誤的抽象層級

編寫方法時，很容易想到，函數應該是一層一層往下調用的，不應該出現地層函數調用高層函數的現象，就像是基類不應該依賴于派生類一樣。

11.封裝條件

在if, while等條件語句中，下面這種寫法：

if(shouldBeDeleted(timer)){}

明顯要好于：

if(timer->hasExpired() && !timer->isRecurrent()){}

12.隱藏調用順序

在一個類中，有這樣一段代碼：

public function eat(Person $p){buyGreens();makeDinner();eatDinner($p); }

這段代碼很好理解，先買菜，然后做飯，最后吃飯。很顯然，買菜的時候會對類的菜品屬性進行賦值，在做飯的時候使用。但如果他們的調用順序寫錯了，就會使用到未初始化的變量。如果改成下面這樣：

public function eat(Person $p){$greens = buyGreens();$dinner = makeDinner($greens);eatDinner($dinner, $p); }

這樣通過函數，暴露了調用順序，每個函數都產出下一個函數所需要的結果，這樣一來就沒理由不按照順序調用了吧。

總結

以上是生活随笔為你收集整理的代码整洁之道小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。