19 條法則，教你寫出火爆 GitHub 的爛代碼！

古人云：好代碼萬里挑一，爛代碼千篇一概。

做爲一名開發者，除了我本身寫的，別人的代碼在我眼裏大部分都是「爛代碼」。但苦於資歷尚欠，因此爛代碼見得並非不少，也沒總結出來什麼規律。但 GitHub 上的這個項目，實現了我多年來的夢想。

垃圾代碼書寫準則

這個項目實際上是一個垃圾代碼書寫準則的列表，一共有 19 項規範。這個項目目前在 GitHub 上已經得到了 600+ Star，我以爲他的潛力絕對不止於此

友情提示：下方截圖中的「Good」表明符合「爛代碼原則」，「Bad」則表明不符合「爛代碼原則」，不要搞錯哦~

1. 以一種容易被混淆的方式命名變量

若是咱們鍵入的東西越少，那麼就有越多的時間去思考代碼邏輯等問題。以下圖因此，將變量命名爲「a」，誰也不知道表明什麼意思，相反，命名爲「age」，就是普普統統的通常貨色了。

2. 變量/函數混合命名風格

爲不一樣慶祝一下。通常人會把變量名稱和函數名稱設定爲同一格式，但使用不一樣風格才能既體現咱們的編碼能力，還能體現出咱們的起名能力，一箭雙鵰。

3. 不要寫註釋

這一點做者給了一個官方吐槽：反正沒人會讀你的代碼，爲何要寫註釋？這一點我深覺得然，寫註釋的人是對本身代碼沒有信心的體現，難道不是麼？（手動狗頭

4. 使用母語寫註釋

若是您違反了「無註釋」原則，那麼至少嘗試用一種不一樣於您用來編寫代碼的語言來編寫註釋。

好比母語是英語的開發者，能夠用日文、韓文或俄文來作註釋，實現一邊寫代碼，一邊進行外語學習。咱們國內的開發者也能夠嘗試用一些小語種來寫註釋，畢竟咱們是神祕的一羣人。

5. 儘量混合不一樣的格式

爲不一樣慶祝一下。在符合代碼規範的狀況下，儘量的混合不一樣的格式，好比示例中的單引號和雙引號。

6. 儘量把代碼寫成一行

相信你們都看過那些「一行代碼xxx」的鐵子，爲何他們一行代碼實現你們就以爲很酷，咱們寫成一行就不行呢？

7. 不要處理錯誤

不管什麼時候發現錯誤，都沒有必要讓任何人知道它。沒有日誌，沒有錯誤彈框。

8. 普遍使用全局變量

做者說這是爲了符合全球化的原則，有道理，有格局。

9. 構建你用不上的變量

以防萬一。雖然如今用不上，萬一以後有用呢？abc 是鐵三角，永遠不能分割。

10. 若是語言容許，不要指定類型和/或不執行類型檢查。

沒有類型纔是最好的類型。

11. 你應該要有運行不到的代碼

做爲「Plan B」，你須要有一些運行不到的代碼，這表示你作了額外的思考。

12. 三角法則

若是寫代碼是一項藝術，那麼三角法則顯然是最有藝術設計感的了。

13. 混合縮進

避免縮進，由於它們會使複雜的代碼在編輯器中佔用更多的空間。若是你不喜歡迴避他們，那就搗個亂，使用混合縮進策略。（這條實在洗不動了）

14. 不要鎖住你的依賴項

以非受控方式更新每一個新安裝的依賴項。爲何堅持使用過去的版本，讓咱們使用最早進的庫版本。

15. 長函數比短函數好

不要把程序邏輯分紅一個個代碼塊。若是 IDE 的搜索中止，而您沒法找到所需的文件或函數，該怎麼辦?

• 一個文件中 10000 行代碼是 OK 的；
• 一個函數體 1000 行代碼是 OK 的；
• 處理許多服務(第三方和內部，也有一些工具、數據庫手寫 ORM 和 jQuery 滑塊)在一個' service.js ' ?也是 OK 的。

16. 不要測試你的代碼

這是重複的而且不須要的工做。

17. 避免代碼風格統一

編寫您想要的代碼，特別是在一個團隊中有多個開發人員的狀況下。這是一個「自由」的原則。不特殊一些，怎麼體現本身的特立獨行！

18. 構建新項目不須要 README 文檔

從一開始咱們就應該保持不寫 README 的好習慣（這個 GItHub 項目就沒有 README，做者也是知行合一了）。

19. 保存沒必要要的代碼

不要刪除不用的代碼，最可能是註釋掉。畢竟寫過的每一行代碼都是咱們曾經流過的汗水，刪掉了別人怎麼知道咱們寫過呢~

玩歸玩，鬧歸鬧，別拿工做開玩笑

有一句話流傳的挺廣：「代碼是給人讀的，順便讓機器執行。」

我以爲頗有道理，雖然代碼是機器語言，但使用和調試仍是由人來進行的，因此仍然須要最大程度的知足人性化的需求和設計思路。

看完那麼多爛代碼的設計規範，其實就是圖一樂，咱們也能從這些爛代碼規範中瞭解到想寫出優秀的的代碼應該避免踩到哪些坑。下面是收集的一些資料，你們能夠先收藏，沒事兒的時候看一看，爭取人人都能寫得一手好代碼~

相關資料

爛代碼指南：
https://github.com/trekhleb/s...

JavaScript 代碼規範（中文版）：
https://github.com/BingKui/ja...

谷歌開源代碼評審規範：
https://github.com/google/eng...

谷歌風格指南：
http://google.github.io/style...

開發人員須要瞭解的定律法則：
https://github.com/dwmkerr/ha...