在 GitHub 上有一個項目，它描述了「最佳垃圾程式碼」的十九個關鍵準則。從變數命名到註解編寫。這些準則將引導你寫出最亮眼的爛程式碼。
為了保持與原始 GitHub 專案一致的風格，下文沒有進行轉換。讀者可以以相反的角度來理解所有觀點，這樣就能完美避免寫出垃圾程式碼。
專案位址：
https://github.com/trekhleb/state-of-the-art-shitcode
當然，以下十九個垃圾程式碼書寫準則並沒有面面俱到，如果讀者們發現有一些難以忍受的爛程式碼習慣，也可以發表你的看法。
? 第一條：打字越少越好
如果我們鍵入的東西越少，那就有越多的時間去思考程式碼邏輯等問題。如下所示，「Good」表示遵循該規則的範例，Bad 表示沒遵循該規則的範例。
? 第二條：變數/函數混合命名風格
我們需要混合命名方法與變量，這樣才能體現命名的多樣性。
?第三條：不要寫註解
反正程式碼都看得懂，為什麼要寫註釋？或者說，反正沒人看我的程式碼，為什麼要寫註解？
?第四條：使用母語寫註解
如果你違反了第三條規則，那麼至少寫註釋需要用你的母語或其它語言。如果你的母語是英語，那麼你也算違反了這條規則。既然程式語言絕大多數都是用英文，那麼為什麼不用其它語言註解一下呢？
?第五條：盡可能混合不同的格式##
同樣，為了程式碼的多樣性，我們需要盡可能混合不同的格式，例如單引號或雙引號。如果它們的語意相同，那就應該混用。
?第六條：盡可能把程式碼寫成一行
如果一系列參數與方法都是一起實現的，那麼程式碼也要寫在一起。
?第七條：發現錯誤要保持靜默
當你發現某些錯誤時，其他人不需要了解它，因此不需要列印出日誌或Traceback。
?第八條：廣泛使用全域變數
使用全域變量，是面向「全球化」不可或缺的部分。
?第九條：建立備用變數
#萬一，我們需要建立一些備用變量，在需要時隨時調用它們。
?第十個：Type 使用需謹慎
一般不要指定變數型別或經常做類型檢查，無類型才是最好的類型。
?第十一條：準備「Plan B」
##你需要準備一些運行不到的程式碼（unreachable code），它們可以作為你的「Plan B」。
?第十二條：巢狀的三角法則
如果程式碼有一些嵌套結構，或者說縮排空行的結構，三角法則是最漂亮的。
?第十三條：混合縮排
我們需要避免採用縮排，因為縮排會使複雜程式碼在編輯器中佔用更多的空間。如果一定要採用縮排，那麼就使用混合縮排策略。當然，這種策略在 Python 中是行不通的，因為它是靠縮進來決定程式碼結構。
?第十四條：不要鎖定依賴項
每次要安裝新程式庫時，更新現有的依賴項。為什麼要維持之前的版本呢，我們需要時時保持最新的第三方程式碼庫。
?第十五條：長函數比短函數好
不要將程式整體邏輯分割成一些程式碼區塊，要是IDE 突然不行了，它找不到必要的檔案或函數怎麼辦。因此把程式碼寫在一個主體函數中，並且不再維護額外的函數導入或程式碼文件，那麼這樣的方法是最穩定的。
單一檔案一萬行程式碼是沒問題的，單一函數一千行程式碼也是沒問題的。
?第十六條：程式碼不需要做特定測試
這些測試通常是重複且無意義的工作。
?第十七條：盡量避免重複程式碼
#按你的想法寫程式碼，尤其是在小團隊中，畢竟這是「自由」準則。
?第十八條：建立新專案不需要 README 文件
#在專案前期，我們可以暫時維持這個狀態。
?第十九條：保存不必要的程式碼
#在寫程式碼的過程中，常常會產生很多測試程式碼。這些程式碼也是非常重要的資料，因此不能刪除掉，最多只能註解掉。
以上是Shit一樣的爛代碼，你愛了嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
