犯錯乃人之常情。

然而，開發人員所犯的許多錯誤是可以避免的。如果能避免本文提到的這些常見錯誤，就能寫出更好、更簡潔的代碼。 這不僅于自身有利，對那些需要查看代碼的其他開發人員也有利。所以避開常見錯誤不僅僅是為自己——也是幫了團隊一個大忙。

綜上所述，小芯這次為大家整理了一系列應避免的常見錯誤：

1. 變量的非描述性命名

好的變量名稱非常重要，再怎么強調也不為過。很多時候，你不是唯一一個項目開發人員，其他開發人員也需要了解你編寫的代碼。

選擇好的名字需要時間，但可以節省更多的時間。

2. 幻數和字符串

接著上文變量的非描述性命名，跳到下一項，該項關于不給變量賦值，也被稱為幻數或魔法字符串。

維基百科定義： 幻數是唯一值，具有無法解釋的意義且多次出現，可以而且應該被命名常量替換。

來看看下面的代碼片段：

for ($i = 1; $i <= 52; $i++) { 
    ... 
} 

該例中的數字52就是一個幻數。沒有人明白為什么有52這個數字及其代表什么。為什么是52?為什么不能是64?這些是一年中的星期總數嗎?

更明晰的方法是：

$cardDeckSize = 52;for ($i = 1;$i <= $cardDeckSize; $i++) { 
    ... 
} 

現在每個人都會明白這是在循環一副紙牌。該代碼給其他開發人員提供了語境。除此之外，更改數值更容易，因為值只在變量中存儲一次，不會重復。

幻數經常在程序的不同位置多次使用，因此容易出錯。

對于字符串來說也是如此，可采用同種方法：

if (userPasswordIsValid($user,"6yP4cZ".$password)) { 
    ... 
} 

6yP4cZ是什么?似乎非常隨意。

$salt = "6yP4cZ";if(userPasswordIsValid($user, $salt.$password)) { 
    ... 
} 

啊哈，現在就說得通了!

3. 代碼格式混亂

混淆代碼的格式通常是那些沒有豐富編程經驗的人才會犯的。如果問有著多年經驗的開發人員，問他們是否認識一個測試人員或數據科學家混淆過代碼格式，他們可能都會點頭。這是由于缺乏經驗——除非使用像Python這樣的編程語言，可以避免很多此類失誤。

解決格式混亂最常見的方法是使用linter(應用代碼校驗)。現代集成開發系統(IDEs)也都有可能解決這個問題。有時需要安裝一個插件，有時也可以直接完成。

4. 在一個函數中進行太多內容

根據單一職責模式，一個函數只應負責做一件事，只有一件事。筆者看到過太多函數集結了獲取、處理并呈現數據三個功能。把這個函數分開處理才是好的編程，一個函數獲取數據，一個函數處理數據，另一個函數顯示數據。

一個函數只關注一個內容之所以重要，是因為這能讓其運行更穩健。比如說，從API(應用程序接口)中獲取數據。如果API有變動——例如，出現了一個新版本——那么如果處理代碼同屬一個函數，那么處理代碼過程中斷的風險就會更大，這很可能會導致數據顯示也被中斷。

5. 硬編碼

硬編碼是將數據直接嵌入到程序或其他可執行對象的源代碼中的軟件開發行為，而不是從外部獲取數據或在運行時生成數據。

硬編碼的值不允許更改;它們是固定值。硬編碼被看作是一種反模式，或者至少是意味著一種壞代碼。

硬編碼最多的東西，不管是什么(有時甚至有效)原因，都是密碼和文件位置。

人們看到的很多硬編碼密碼場景是用于外部服務或API的身份驗證。這些證書往往被硬編碼，但并不是最佳做法。

如果發現自己硬編碼了很多東西，真的應該仔細審視自己寫的代碼，因為大多數時候這都不是解決問題的最好方法。

6. 注釋掉代碼

人們看到過包含多個函數的代碼塊被注釋掉。沒人知道為什么它還在那里，而且沒人知道這段代碼是否還有意義。但是，沒人會刪除這段代碼，而這是開發人員真正應該做的事情。之所以沒人刪除這段代碼，是因為每個人都認為其他人可能會用到。

只需刪除那段注釋掉的代碼即可。即使代碼不在最新版本中，如果有人想使用，該代碼仍然可以在版本控制中使用。

不過這只是筆者的個人看法。

祝大家避免雷區，代碼愉悅~