雲栖号： https://yqh.aliyun.com 第一手的上雲資訊，不同行業精選的上雲企業案例庫，基于衆多成功案例萃取而成的最佳實踐，助力您上雲決策！
圖源：Unsplash
犯錯乃人之常情。
然而，開發人員所犯的許多錯誤是可以避免的。如果能避免本文提到的這些常見錯誤，就能寫出更好、更簡潔的代碼。
這不僅于自身有利，對那些需要檢視代碼的其他開發人員也有利。是以避開常見錯誤不僅僅是為自己——也是幫了團隊一個大忙。
綜上所述，小芯這次為大家整理了一系列應避免的常見錯誤：
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. 注釋掉代碼
人們看到過包含多個函數的代碼塊被注釋掉。沒人知道為什麼它還在那裡，而且沒人知道這段代碼是否還有意義。但是，沒人會删除這段代碼，而這是開發人員真正應該做的事情。之是以沒人删除這段代碼，是因為每個人都認為其他人可能會用到。
隻需删除那段注釋掉的代碼即可。即使代碼不在最新版本中，如果有人想使用，該代碼仍然可以在版本控制中使用。
不過這隻是筆者的個人看法。
祝大家避免雷區，代碼愉悅~
原文釋出時間：2020-01-30
本文作者：讀芯術
本文來自：“
讀芯術”，了解相關資訊可以關注“
”