最怕同事寫出這樣的代碼。。。
在 GitHub 上有一個項目，它描述了「最佳垃圾代碼」的十九條關(guān)鍵準則。從變量命名到注釋編寫，這些準則將指導你寫出最亮眼的爛代碼。
為了保持與原 GitHub 項目一致的風格，下文沒有進行轉(zhuǎn)換。讀者們可以以相反的角度來理解所有觀點，這樣就能完美避免寫出垃圾代碼。
項目地址：
https://github.com/trekhleb/state-of-the-art-shitcode
當然，以下十九條垃圾代碼書寫準則并沒有面面俱到，如果讀者們發(fā)現(xiàn)有一些難以忍受的爛代碼習慣，也可以發(fā)表你的看法。
?? 第一條：打字越少越好
如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。如下所示，「Good」表示遵循該規(guī)則的示例，Bad 表示沒遵循該規(guī)則的示例。
?? 第二條：變量/函數(shù)混合命名風格
我們需要混合命名方法與變量，這樣才能體現(xiàn)命名的多樣性。
??第三條：不要寫注釋
反正代碼都看得懂，為什么要寫注釋？或者說，反正沒人看我的代碼，為什么要寫注釋？
??第四條：使用母語寫注釋
如果你違反了第三條規(guī)則，那么至少寫注釋需要用你的母語或者其它語言。如果你的母語是英語，那么你也算違反了這條規(guī)則。既然編程語言絕大多數(shù)都是用英文，那么為什么不用其它語言注釋一下？
??第五條：盡可能混合不同的格式
同樣，為了代碼的多樣性，我們需要盡可能混合不同的格式，例如單引號或雙引號。如果它們的語義相同，那就應該混用。
??第六條：盡可能把代碼寫成一行
如果一系列參數(shù)與方法都是一起實現(xiàn)的，那么代碼也要寫在一起。
??第七條：發(fā)現(xiàn)錯誤要保持靜默
當你發(fā)現(xiàn)某些錯誤時，其他人不需要了解它，因此不需要打印出日志或 Traceback。
??第八條：廣泛使用全局變量
使用全局變量，是面向「全球化」不可或缺的部分。
??第九條：構(gòu)建備用變量
以防萬一，我們需要創(chuàng)建一些備用變量，在需要時隨時調(diào)用它們。
??第十條：Type 使用需謹慎
一般不要指定變量類型或者經(jīng)常做類型檢查，無類型才是最好的類型。
??第十一條：準備「Plan B」
你需要準備一些運行不到的代碼（unreachable code），它們可以作為你的「Plan B」。
??第十二條：嵌套的三角法則
如果代碼有一些嵌套結(jié)構(gòu)，或者說縮進空行的結(jié)構(gòu)，三角法則是最漂亮的。
??第十三條：混合縮進
我們需要避免采用縮進，因為縮進會使復雜代碼在編輯器中占用更多的空間。如果一定要采用縮進，那么就使用混合縮進策略。當然，這種策略在 Python 中是行不通的，因為它靠縮進來確定代碼結(jié)構(gòu)。
??第十四條：不要鎖住依賴項
每一次要安裝新庫時，更新已有的依賴項。為什么要維持之前的版本呢，我們需要時刻保持最新的第三方代碼庫。
??第十五條：長函數(shù)比短函數(shù)好
不要將程序整體邏輯分割為一些代碼塊，要是 IDE 突然不行了，它找不到必要的文件或函數(shù)怎么辦。因此把代碼寫在一個主體函數(shù)中，并且不再維護額外的函數(shù)導入或代碼文件，那么這樣的方法是最穩(wěn)定的。
單個文件一萬行代碼是沒問題的，單個函數(shù)一千行代碼也是沒問題的。
??第十六條：代碼不需要做特定測試
這些測試通常是重復且無意義的工作。
??第十七條：盡量避免重復代碼
按你的想法寫代碼，尤其是在小團隊中，畢竟這是「自由」準則。
??第十八條：構(gòu)建新項目不需要 README 文檔
在項目前期，我們可以暫時保持這種狀態(tài)。
??第十九條：保存不必要的代碼
在寫代碼的過程中，經(jīng)常會產(chǎn)生很多測試代碼。這些代碼也是非常重要的資料，因此不能刪除掉，最多只能注釋掉。
（完）
碼農(nóng)突圍資料鏈接
1、臥槽！字節(jié)跳動《算法中文手冊》火了，完整版 PDF 開放下載！
2、計算機基礎(chǔ)知識總結(jié)與操作系統(tǒng) PDF 下載
3、艾瑪，終于來了！《LeetCode Java版題解》.PDF
4、Github 10K+，《LeetCode刷題C/C++版答案》出爐.PDF歡迎添加魚哥個人微信：smartfish2020，進粉絲群或圍觀朋友圈。