如果說到什麼是好程式碼，我們肯定都能說出一堆規則，例如使用一致的格式和縮排、使用清晰的變數名和方法名、在必要時提供文件與註釋、不要過度精簡程式碼等等。

但是對於什麼是爛程式碼，你有比較清晰的認識嗎？

在 GitHub 上有一個新專案，它描述了「最佳垃圾程式碼」的十九條關鍵準則。從變數命名到註釋編寫。這些準則將指導你寫出最亮眼的爛程式碼。

無論程式碼寫成什麼樣子java的基礎你必須打好！想要打好Java的基礎，那就不得不反向種草一個免費的java基礎課程，某個小破站上的java300集，堪稱一大java基礎殺器

學好基礎，打的一手好程式碼，人生贏家就是你，java300集你值得擁有！

繼續正題

為了保持與原 GitHub 專案一致的風格，下文沒有進行轉換。讀者們可以以相反的角度來理解所有觀點，這樣就能完美避免寫出垃圾程式碼。
當然，以下十九條垃圾程式碼書寫準則並沒有面面俱到，可以留言發表你的看法。

第一條：打字越少越好

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

第二條：變數/函式混合命名風格

我們需要混合命名方法與變數，這樣才能體現命名的多樣性。

第三條：不要寫註釋

反正程式碼都看得懂，為什麼要寫註釋？或者說，反正沒人看我的程式碼，為什麼要寫註釋？

第四條：使用母語寫註釋

如果你違反了第三條規則，那麼至少寫註釋需要用你的母語或者其它語言。如果你的母語是英語，那麼你也算違反了這條規則。既然程式語言絕大多數都是用英文，那麼為什麼不用其它語言註釋一下？

第五條：儘可能混合不同的格式

同樣，為了程式碼的多樣性，我們需要儘可能混合不同的格式，例如單引號或雙引號。如果它們的語義相同，那就應該混用。

第六條：儘可能把程式碼寫成一行

如果一系列引數與方法都是一起實現的，那麼程式碼也要寫在一起。

第七條：發現錯誤要保持靜默

當你發現某些錯誤時，其他人不需要了解它，因此不需要打印出日誌或 Traceback。

第八條：廣泛使用全域性變數

使用全域性變數，是面向「全球化」不可或缺的部分。

第九條：構建備用變數

以防萬一，我們需要建立一些備用變數，在需要時隨時呼叫它們。

第十條：Type 使用需謹慎

一般不要指定變數型別或者經常做型別檢查，無型別才是最好的型別。

第十一條：準備「Plan B」

你需要準備一些執行不到的程式碼（unreachable code），它們可以作為你的「Plan B」。

第十二條：巢狀的三角法則

如果程式碼有一些巢狀結構，或者說縮排空行的結構，三角法則是最漂亮的。

第十三條：混合縮排

我們需要避免採用縮排，因為縮排會使複雜程式碼在編輯器中佔用更多的空間。如果一定要採用縮排，那麼就使用混合縮排策略。當然，這種策略在 Python 中是行不通的，因為它靠縮排來確定程式碼結構。

第十四條：不要鎖住依賴項

每一次要安裝新庫時，更新已有的依賴項。為什麼要維持之前的版本呢，我們需要時刻保持最新的第三方程式碼庫。

第十五條：長函式比短函式好

不要將程式整體邏輯分割為一些程式碼塊，要是 IDE 突然不行了，它找不到必要的檔案或函式怎麼辦。因此把程式碼寫在一個主體函式中，並且不再維護額外的函式匯入或程式碼檔案，那麼這樣的方法是最穩定的。

單個檔案一萬行程式碼是沒問題的，單個函式一千行程式碼也是沒問題的。

第十六條：程式碼不需要做特定測試

這些測試通常是重複且無意義的工作。

第十七條：儘量避免重複程式碼

按你的想法寫程式碼，尤其是在小團隊中，畢竟這是「自由」準則。

第十八條：構建新專案不需要 README 文件

在專案前期，我們可以暫時保持這種狀態。

第十九條：儲存不必要的程式碼

在寫程式碼的過程中，經常會產生很多測試程式碼。這些程式碼也是非常重要的資料，因此不能刪除掉，最多隻能註釋掉。

Hello 程式設計小菜鳥

————————————————
版權宣告：本文為CSDN博主「Hello 程式設計小菜鳥」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/sxt_112233/article/details/119668859