要是想寫個爛代碼，咱們只需遵照這十九條準則？
「代碼寫得好」是對機器學習研究者及開發者最好的讚賞。其第一層意思是說，你的模型很是好，有本身的理解與修正；第二層意思是說代碼的結構、命名規則、編寫邏輯都很是優秀。git
咱們曾經將寫代碼比喻成寫文章：不只須要有一個主旨，告訴別人代碼的做用是什麼，同時還應該在精煉與易讀之間作權衡。代碼過於精煉，總體邏輯難以跟隨，代碼過於易讀，總體就顯得比較臃腫。github
在精簡與易讀之間作權衡，第一種方法根據列表推導式能得到更精簡的代碼，但第二種方法更易讀。web
若是說到什麼是好代碼，咱們確定都能說出一堆規則，例如使用一致的格式和縮進、使用清晰的變量名和方法名、在必要時提供文檔與註釋、不要過分精簡代碼等等。編程
可是對於什麼是爛代碼，你有比較清晰的認識嗎？微信
在 GitHub 上有一個新項目，它描述了「最佳垃圾代碼」的十九條關鍵準則。從變量命名到註釋編寫。這些準則將指導你寫出最亮眼的爛代碼。機器學習
爲了保持與原 GitHub 項目一致的風格，下文沒有進行轉換。讀者們能夠以相反的角度來理解全部觀點，這樣就能完美避免寫出垃圾代碼。編程語言
項目地址：https://github.com/trekhleb/state-of-the-art-shitcode編輯器
固然，如下十九條垃圾代碼書寫準則並無面面俱到，若是讀者們發現有一些難以忍受的爛代碼習慣，也能夠留言發表你的見解。函數
第一條：打字越少越好學習
若是咱們鍵入的東西越少，那麼就有越多的時間去思考代碼邏輯等問題。以下所示，「Good」表示遵循該規則的示例，Bad 表示沒遵循該規則的示例。
第二條：變量/函數混合命名風格
咱們須要混合命名方法與變量，這樣才能體現命名的多樣性。
第三條：不要寫註釋
反正代碼都看得懂，爲何要寫註釋？或者說，反正沒人看個人代碼，爲何要寫註釋？
第四條：使用母語寫註釋
若是你違反了第三條規則，那麼至少寫註釋須要用你的母語或者其它語言。若是你的母語是英語，那麼你也算違反了這條規則。既然編程語言絕大多數都是用英文，那麼爲何不用其它語言註釋一下？
第五條：儘量混合不一樣的格式
一樣，爲了代碼的多樣性，咱們須要儘量混合不一樣的格式，例如單引號或雙引號。若是它們的語義相同，那就應該混用。
第六條：儘量把代碼寫成一行
若是一系列參數與方法都是一塊兒實現的，那麼代碼也要寫在一塊兒。
第七條：發現錯誤要保持靜默
當你發現某些錯誤時，其餘人不須要了解它，所以不須要打印出日誌或 Traceback。
第八條：普遍使用全局變量
使用全局變量，是面向「全球化」不可或缺的部分。
第九條：構建備用變量
以防萬一，咱們須要建立一些備用變量，在須要時隨時調用它們。
第十條：Type 使用需謹慎
通常不要指定變量類型或者常常作類型檢查，無類型纔是最好的類型。
第十一條：準備「Plan B」
你須要準備一些運行不到的代碼（unreachable code），它們能夠做爲你的「Plan B」。
第十二條：嵌套的三角法則
若是代碼有一些嵌套結構，或者說縮進空行的結構，三角法則是最漂亮的。
第十三條：混合縮進
咱們須要避免採用縮進，由於縮進會使複雜代碼在編輯器中佔用更多的空間。若是必定要採用縮進，那麼就使用混合縮進策略。固然，這種策略在 Python 中是行不通的，由於它靠縮進來肯定代碼結構。
第十四條：不要鎖住依賴項
每一次要安裝新庫時，更新已有的依賴項。爲何要維持以前的版本呢，咱們須要時刻保持最新的第三方代碼庫。
第十五條：長函數比短函數好
不要將程序總體邏輯分割爲一些代碼塊，要是 IDE 忽然不行了，它找不到必要的文件或函數怎麼辦。所以把代碼寫在一個主體函數中，而且再也不維護額外的函數導入或代碼文件，那麼這樣的方法是最穩定的。
單個文件一萬行代碼是沒問題的，單個函數一千行代碼也是沒問題的。
第十六條：代碼不須要作特定測試
這些測試一般是重複且無心義的工做。
第十七條：儘可能避免重複代碼
按你的想法寫代碼，尤爲是在小團隊中，畢竟這是「自由」準則。
第十八條：構建新項目不須要 README 文檔
在項目前期，咱們能夠暫時保持這種狀態。
第十九條：保存沒必要要的代碼
在寫代碼的過程當中，常常會產生不少測試代碼。這些代碼也是很是重要的資料，所以不能刪除掉，最多隻能註釋掉。
掃描下方二維碼
加入優質社羣一塊兒交流吧！
如若二維碼過時
請添加小編微信,回覆關鍵詞：[進羣/加羣],
-今日互動-
哪條準則最深得你心呢？歡迎文章下方留言互動
若是對你有幫助的話
❤️來個「轉發朋友圈」和「在看」，是最大的支持❤️
本文分享自微信公衆號 - DataScience（DataScienceTeam）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。