開發

這個教人寫出爛代碼的項目在 GitHub 上火了…

如果說到什么是好代碼,我們肯定都能說出一堆規則,例如使用一致的格式和縮進、使用清晰的變量名和方法名、在必要時提供文檔與注釋、不要過度精簡代碼等等。但是對于什么是爛代碼,你有比較清晰的認識嗎?在 GitHub 上有一個新項目,它描述了「最佳垃圾代碼」的十九條關鍵準則。從變量命名到注釋編寫。這些準則將指導你寫出最亮眼的爛代碼。

為了保持與原 GitHub 項目一致的風格,下文沒有進行轉換。讀者們可以以相反的角度來理解所有觀點,這樣就能完美避免寫出垃圾代碼。

項目地址:https://github.com/trekhleb/state-of-the-art-shitcode

當然,以下十九條垃圾代碼書寫準則并沒有面面俱到,如果讀者們發現有一些難以忍受的爛代碼習慣,也可以留言發表你的看法。

第一條:打字越少越好

如果我們鍵入的東西越少,那么就有越多的時間去思考代碼邏輯等問題。如下所示,「Good」表示遵循該規則的示例,Bad 表示沒遵循該規則的示例。

第二條:變量/函數混合命名風格
我們需要混合命名方法與變量,這樣才能體現命名的多樣性。

第三條:不要寫注釋
反正代碼都看得懂,為什么要寫注釋?或者說,反正沒人看我的代碼,為什么要寫注釋?

第四條:使用母語寫注釋
如果你違反了第三條規則,那么至少寫注釋需要用你的母語或者其它語言。如果你的母語是英語,那么你也算違反了這條規則。既然編程語言絕大多數都是用英文,那么為什么不用其它語言注釋一下?

第五條:盡可能混合不同的格式
同樣,為了代碼的多樣性,我們需要盡可能混合不同的格式,例如單引號或雙引號。如果它們的語義相同,那就應該混用。

第六條:盡可能把代碼寫成一行
如果一系列參數與方法都是一起實現的,那么代碼也要寫在一起。

第七條:發現錯誤要保持靜默
當你發現某些錯誤時,其他人不需要了解它,因此不需要打印出日志或 Traceback。

第八條:廣泛使用全局變量
使用全局變量,是面向「全球化」不可或缺的部分。

第九條:構建備用變量
以防萬一,我們需要創建一些備用變量,在需要時隨時調用它們。

第十條:Type 使用需謹慎
一般不要指定變量類型或者經常做類型檢查,無類型才是最好的類型。

第十一條:準備「Plan B」
你需要準備一些運行不到的代碼(unreachable code),它們可以作為你的「Plan B」。

第十二條:嵌套的三角法則
如果代碼有一些嵌套結構,或者說縮進空行的結構,三角法則是最漂亮的。

第十三條:混合縮進
我們需要避免采用縮進,因為縮進會使復雜代碼在編輯器中占用更多的空間。如果一定要采用縮進,那么就使用混合縮進策略。當然,這種策略在 Python 中是行不通的,因為它靠縮進來確定代碼結構。

第十四條:不要鎖住依賴項
每一次要安裝新庫時,更新已有的依賴項。為什么要維持之前的版本呢,我們需要時刻保持最新的第三方代碼庫。

第十五條:長函數比短函數好
不要將程序整體邏輯分割為一些代碼塊,要是 IDE 突然不行了,它找不到必要的文件或函數怎么辦。因此把代碼寫在一個主體函數中,并且不再維護額外的函數導入或代碼文件,那么這樣的方法是最穩定的。
單個文件一萬行代碼是沒問題的,單個函數一千行代碼也是沒問題的。
第十六條:代碼不需要做特定測試
這些測試通常是重復且無意義的工作。
第十七條:盡量避免重復代碼
按你的想法寫代碼,尤其是在小團隊中,畢竟這是「自由」準則。
第十八條:構建新項目不需要 README 文檔
在項目前期,我們可以暫時保持這種狀態。
第十九條:保存不必要的代碼
在寫代碼的過程中,經常會產生很多測試代碼。這些代碼也是非常重要的資料,因此不能刪除掉,最多只能注釋掉。

轉自:機器之心

我還沒有學會寫個人說明!

在線教育需求爆發,23萬家在線教育機構將受益于電子合同

上一篇

虛擬化Pod性能比裸機還要好,原因竟然是這樣!

下一篇

你也可能喜歡

這個教人寫出爛代碼的項目在 GitHub 上火了…

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
双色球常规走势图 友乐广西麻将作弊器 36选7几点开奖 山东老十一选五开奖 排列三和值和尾走势图彩宝网 八闽福建麻将群 甘肃十一选五 广东省福利*36选7 澳门即时指数 双色球3d开奖结果 青海十一选五 海南麻将怎么打初学图解 明天有什么好股票推荐