寫出一手爛程式碼的19條準則
- 2020 年 2 月 23 日
- 筆記
機器之心報道
參與：思
要是想寫個爛程式碼，我們只需遵守這十九條準則？
「程式碼寫得好」是對機器學習研究者及開發者最好的讚揚。其第一層意思是說，你的模型非常好，有自己的理解與修正；第二層意思是說程式碼的結構、命名規則、編寫邏輯都非常優秀。
我們曾經將寫程式碼比喻成寫文章：不僅需要有一個主旨，告訴別人程式碼的作用是什麼，同時還應該在精鍊與易讀之間做權衡。程式碼過於精鍊，整體邏輯難以跟隨，程式碼過於易讀，整體就顯得比較臃腫。
在精簡與易讀之間做權衡，第一種方法根據列表推導式能獲得更精簡的程式碼，但第二種方法更易讀。
如果說到什麼是好程式碼，我們肯定都能說出一堆規則，例如使用一致的格式和縮進、使用清晰的變數名和方法名、在必要時提供文檔與注釋、不要過度精簡程式碼等等。
但是對於什麼是爛程式碼，你有比較清晰的認識嗎？
在 GitHub 上有一個新項目，它描述了「最佳垃圾程式碼」的十九條關鍵準則。從變數命名到注釋編寫。這些準則將指導你寫出最亮眼的爛程式碼。
為了保持與原 GitHub 項目一致的風格，下文沒有進行轉換。讀者們可以以相反的角度來理解所有觀點，這樣就能完美避免寫出垃圾程式碼。
項目地址：https://github.com/trekhleb/state-of-the-art-shitcode
當然，以下十九條垃圾程式碼書寫準則並沒有面面俱到，如果讀者們發現有一些難以忍受的爛程式碼習慣，也可以留言發表你的看法。
第一條：打字越少越好
如果我們鍵入的東西越少，那麼就有越多的時間去思考程式碼邏輯等問題。如下所示，「Good」表示遵循該規則的示例，Bad 表示沒遵循該規則的示例。
第二條：變數/函數混合命名風格
我們需要混合命名方法與變數，這樣才能體現命名的多樣性。
第三條：不要寫注釋
反正程式碼都看得懂，為什麼要寫注釋？或者說，反正沒人看我的程式碼，為什麼要寫注釋？
第四條：使用母語寫注釋
如果你違反了第三條規則，那麼至少寫注釋需要用你的母語或者其它語言。如果你的母語是英語，那麼你也算違反了這條規則。既然程式語言絕大多數都是用英文，那麼為什麼不用其它語言注釋一下？
第五條：儘可能混合不同的格式
同樣，為了程式碼的多樣性，我們需要儘可能混合不同的格式，例如單引號或雙引號。如果它們的語義相同，那就應該混用。
第六條：儘可能把程式碼寫成一行
如果一系列參數與方法都是一起實現的，那麼程式碼也要寫在一起。
第七條：發現錯誤要保持靜默
當你發現某些錯誤時，其他人不需要了解它，因此不需要列印出日誌或 Traceback。
第八條：廣泛使用全局變數
使用全局變數，是面向「全球化」不可或缺的部分。
第九條：構建備用變數
以防萬一，我們需要創建一些備用變數，在需要時隨時調用它們。
第十條：Type 使用需謹慎
一般不要指定變數類型或者經常做類型檢查，無類型才是最好的類型。
第十一條：準備「Plan B」
你需要準備一些運行不到的程式碼（unreachable code），它們可以作為你的「Plan B」。
第十二條：嵌套的三角法則
如果程式碼有一些嵌套結構，或者說縮進空行的結構，三角法則是最漂亮的。
第十三條：混合縮進
我們需要避免採用縮進，因為縮進會使複雜程式碼在編輯器中佔用更多的空間。如果一定要採用縮進，那麼就使用混合縮進策略。當然，這種策略在 Python 中是行不通的，因為它靠縮進來確定程式碼結構。
第十四條：不要鎖住依賴項
每一次要安裝新庫時，更新已有的依賴項。為什麼要維持之前的版本呢，我們需要時刻保持最新的第三方程式碼庫。
第十五條：長函數比短函數好
不要將程式整體邏輯分割為一些程式碼塊，要是 IDE 突然不行了，它找不到必要的文件或函數怎麼辦。因此把程式碼寫在一個主體函數中，並且不再維護額外的函數導入或程式碼文件，那麼這樣的方法是最穩定的。
單個文件一萬行程式碼是沒問題的，單個函數一千行程式碼也是沒問題的。
第十六條：程式碼不需要做特定測試
這些測試通常是重複且無意義的工作。
第十七條：盡量避免重複程式碼
按你的想法寫程式碼，尤其是在小團隊中，畢竟這是「自由」準則。
第十八條：構建新項目不需要 README 文檔
在項目前期，我們可以暫時保持這種狀態。
第十九條：保存不必要的程式碼
在寫程式碼的過程中，經常會產生很多測試程式碼。這些程式碼也是非常重要的資料，因此不能刪除掉，最多只能注釋掉。
本文為機器之心報道，轉載請聯繫本公眾號獲得授權。
✄————————————————
加入機器之心（全職記者 / 實習生）：[email protected]
投稿或尋求報道：[email protected]
廣告 & 商務合作：[email protected]
