19 條法則，教你寫出火爆 GitHub 的爛代碼！
古人云：好代碼萬里挑一，爛代碼千篇一律。
作為一名開發(fā)者，除了我自己寫的，別人的代碼在我眼里大部分都是「爛代碼」。但苦于資歷尚欠，所以爛代碼見得并不是很多，也沒總結出來什么規(guī)律。但 GitHub 上的這個項目，實現(xiàn)了我多年來的夢想。
垃圾代碼書寫準則
這個項目其實是一個垃圾代碼書寫準則的列表，一共有 19 項規(guī)范。這個項目目前在 GitHub 上已經(jīng)獲得了 600+ Star，我覺得他的潛力絕對不止于此
友情提示：下方截圖中的「Good」代表符合「爛代碼原則」，「Bad」則代表不符合「爛代碼原則」，不要搞錯哦~
1. 以一種容易被混淆的方式命名變量
如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。如下圖所以，將變量命名為「a」，誰也不知道代表什么意思，相反，命名為「age」，就是普普通通的一般貨色了。
2. 變量/函數(shù)混合命名風格
為不同慶祝一下。一般人會把變量名稱和函數(shù)名稱設定為同一格式，但使用不同風格才能既體現(xiàn)我們的編碼能力，還能體現(xiàn)出我們的起名能力，一舉兩得。
3. 不要寫注釋
這一點作者給了一個官方吐槽：反正沒人會讀你的代碼，為什么要寫注釋?這一點我深以為然，寫注釋的人是對自己代碼沒有信心的體現(xiàn)，難道不是么?(手動狗頭
4. 使用母語寫注釋
如果您違反了“無注釋”原則，那么至少嘗試用一種不同于您用來編寫代碼的語言來編寫注釋。
比如母語是英語的開發(fā)者，可以用日文、韓文或俄文來做注釋，實現(xiàn)一邊寫代碼，一邊進行外語學習。我們國內的開發(fā)者也可以嘗試用一些小語種來寫注釋，畢竟我們是神秘的一群人。
5. 盡可能混合不同的格式
為不同慶祝一下。在符合代碼規(guī)范的情況下，盡可能的混合不同的格式，比如示例中的單引號和雙引號。
6. 盡可能把代碼寫成一行
相信大家都看過那些“一行代碼xxx”的鐵子，為什么他們一行代碼實現(xiàn)大家就覺得很酷，我們寫成一行就不行呢?
7. 不要處理錯誤
無論何時發(fā)現(xiàn)錯誤，都沒有必要讓任何人知道它。沒有日志，沒有錯誤彈框。
8. 廣泛使用全局變量
作者說這是為了符合全球化的原則，有道理，有格局。
9. 構建你用不上的變量
以防萬一。雖然現(xiàn)在用不上，萬一之后有用呢?abc 是鐵三角，永遠不能分割。
10. 如果語言允許，不要指定類型和/或不執(zhí)行類型檢查。
沒有類型才是最好的類型。
11. 你應該要有運行不到的代碼
作為「Plan B」，你需要有一些運行不到的代碼，這表示你做了額外的思考。
12. 三角法則
如果寫代碼是一項藝術，那么三角法則顯然是最有藝術設計感的了。
13. 混合縮進
避免縮進，因為它們會使復雜的代碼在編輯器中占用更多的空間。如果你不喜歡回避他們，那就搗個亂，使用混合縮進策略。(這條實在洗不動了)
14. 不要鎖住你的依賴項
以非受控方式更新每個新安裝的依賴項。為什么堅持使用過去的版本，讓我們使用最先進的庫版本。
15. 長函數(shù)比短函數(shù)好
不要把程序邏輯分成一個個代碼塊。如果 IDE 的搜索停止，而您無法找到所需的文件或函數(shù)，該怎么辦?
- 一個文件中 10000 行代碼是 OK 的;
- 一個函數(shù)體 1000 行代碼是 OK 的;
- 處理許多服務(第三方和內部，也有一些工具、數(shù)據(jù)庫手寫 ORM 和 jQuery 滑塊)在一個' service.js ' ?也是 OK 的。
16. 不要測試你的代碼
這是重復的并且不需要的工作。
17. 避免代碼風格統(tǒng)一
編寫您想要的代碼，特別是在一個團隊中有多個開發(fā)人員的情況下。這是一個“自由”的原則。不特殊一些，怎么體現(xiàn)自己的特立獨行!
18. 構建新項目不需要 README 文檔
從一開始我們就應該保持不寫 README 的好習慣(這個 GItHub 項目就沒有 README，作者也是知行合一了)。
19. 保存不必要的代碼
不要刪除不用的代碼，最多是注釋掉。畢竟寫過的每一行代碼都是我們曾經(jīng)流過的汗水，刪掉了別人怎么知道我們寫過呢~
玩歸玩，鬧歸鬧，別拿工作開玩笑
有一句話流傳的挺廣：“代碼是給人讀的，順便讓機器執(zhí)行。”
我覺得很有道理，雖然代碼是機器語言，但使用和調試還是由人來進行的，所以仍然需要最大程度的滿足人性化的需求和設計思路。
看完那么多爛代碼的設計規(guī)范，其實就是圖一樂，我們也能從這些爛代碼規(guī)范中了解到想寫出優(yōu)秀的的代碼應該避免踩到哪些坑。下面是收集的一些資料，大家可以先收藏，沒事兒的時候看一看，爭取人人都能寫得一手好代碼~
