古人云：好代碼萬(wàn)里挑一，爛代碼千篇一律。

[[316432]]

作為一名開(kāi)發(fā)者，除了我自己寫(xiě)的，別人的代碼在我眼里大部分都是「爛代碼」。但苦于資歷尚欠，所以爛代碼見(jiàn)得并不是很多，也沒(méi)總結(jié)出來(lái)什么規(guī)律。但 GitHub 上的這個(gè)項(xiàng)目，實(shí)現(xiàn)了我多年來(lái)的夢(mèng)想。

垃圾代碼書(shū)寫(xiě)準(zhǔn)則

這個(gè)項(xiàng)目其實(shí)是一個(gè)垃圾代碼書(shū)寫(xiě)準(zhǔn)則的列表，一共有 19 項(xiàng)規(guī)范。這個(gè)項(xiàng)目目前在 GitHub 上已經(jīng)獲得了 600+ Star，我覺(jué)得他的潛力絕對(duì)不止于此

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

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

如果我們鍵入的東西越少，那么就有越多的時(shí)間去思考代碼邏輯等問(wèn)題。如下圖所以，將變量命名為「a」，誰(shuí)也不知道代表什么意思，相反，命名為「age」，就是普普通通的一般貨色了。

2. 變量/函數(shù)混合命名風(fēng)格

為不同慶祝一下。一般人會(huì)把變量名稱(chēng)和函數(shù)名稱(chēng)設(shè)定為同一格式，但使用不同風(fēng)格才能既體現(xiàn)我們的編碼能力，還能體現(xiàn)出我們的起名能力，一舉兩得。

3. 不要寫(xiě)注釋

這一點(diǎn)作者給了一個(gè)官方吐槽：反正沒(méi)人會(huì)讀你的代碼，為什么要寫(xiě)注釋?這一點(diǎn)我深以為然，寫(xiě)注釋的人是對(duì)自己代碼沒(méi)有信心的體現(xiàn)，難道不是么?(手動(dòng)狗頭

4. 使用母語(yǔ)寫(xiě)注釋

如果您違反了“無(wú)注釋”原則，那么至少?lài)L試用一種不同于您用來(lái)編寫(xiě)代碼的語(yǔ)言來(lái)編寫(xiě)注釋。

比如母語(yǔ)是英語(yǔ)的開(kāi)發(fā)者，可以用日文、韓文或俄文來(lái)做注釋?zhuān)瑢?shí)現(xiàn)一邊寫(xiě)代碼，一邊進(jìn)行外語(yǔ)學(xué)習(xí)。我們國(guó)內(nèi)的開(kāi)發(fā)者也可以嘗試用一些小語(yǔ)種來(lái)寫(xiě)注釋?zhuān)吘刮覀兪巧衩氐囊蝗喝恕?/p>

5. 盡可能混合不同的格式

為不同慶祝一下。在符合代碼規(guī)范的情況下，盡可能的混合不同的格式，比如示例中的單引號(hào)和雙引號(hào)。

6. 盡可能把代碼寫(xiě)成一行

相信大家都看過(guò)那些“一行代碼xxx”的鐵子，為什么他們一行代碼實(shí)現(xiàn)大家就覺(jué)得很酷，我們寫(xiě)成一行就不行呢?

7. 不要處理錯(cuò)誤

無(wú)論何時(shí)發(fā)現(xiàn)錯(cuò)誤，都沒(méi)有必要讓任何人知道它。沒(méi)有日志，沒(méi)有錯(cuò)誤彈框。

8. 廣泛使用全局變量

作者說(shuō)這是為了符合全球化的原則，有道理，有格局。

9. 構(gòu)建你用不上的變量

以防萬(wàn)一。雖然現(xiàn)在用不上，萬(wàn)一之后有用呢?abc 是鐵三角，永遠(yuǎn)不能分割。

10. 如果語(yǔ)言允許，不要指定類(lèi)型和/或不執(zhí)行類(lèi)型檢查。

沒(méi)有類(lèi)型才是最好的類(lèi)型。

11. 你應(yīng)該要有運(yùn)行不到的代碼

作為「Plan B」，你需要有一些運(yùn)行不到的代碼，這表示你做了額外的思考。

12. 三角法則

如果寫(xiě)代碼是一項(xiàng)藝術(shù)，那么三角法則顯然是最有藝術(shù)設(shè)計(jì)感的了。

13. 混合縮進(jìn)

避免縮進(jìn)，因?yàn)樗鼈儠?huì)使復(fù)雜的代碼在編輯器中占用更多的空間。如果你不喜歡回避他們，那就搗個(gè)亂，使用混合縮進(jìn)策略。(這條實(shí)在洗不動(dòng)了)

14. 不要鎖住你的依賴(lài)項(xiàng)

以非受控方式更新每個(gè)新安裝的依賴(lài)項(xiàng)。為什么堅(jiān)持使用過(guò)去的版本，讓我們使用最先進(jìn)的庫(kù)版本。

15. 長(zhǎng)函數(shù)比短函數(shù)好

不要把程序邏輯分成一個(gè)個(gè)代碼塊。如果 IDE 的搜索停止，而您無(wú)法找到所需的文件或函數(shù)，該怎么辦?

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

16. 不要測(cè)試你的代碼

這是重復(fù)的并且不需要的工作。

17. 避免代碼風(fēng)格統(tǒng)一

編寫(xiě)您想要的代碼，特別是在一個(gè)團(tuán)隊(duì)中有多個(gè)開(kāi)發(fā)人員的情況下。這是一個(gè)“自由”的原則。不特殊一些，怎么體現(xiàn)自己的特立獨(dú)行!

18. 構(gòu)建新項(xiàng)目不需要 README 文檔

從一開(kāi)始我們就應(yīng)該保持不寫(xiě) README 的好習(xí)慣(這個(gè) GItHub 項(xiàng)目就沒(méi)有 README，作者也是知行合一了)。

19. 保存不必要的代碼

不要?jiǎng)h除不用的代碼，最多是注釋掉。畢竟寫(xiě)過(guò)的每一行代碼都是我們?cè)?jīng)流過(guò)的汗水，刪掉了別人怎么知道我們寫(xiě)過(guò)呢~

玩歸玩，鬧歸鬧，別拿工作開(kāi)玩笑

有一句話(huà)流傳的挺廣：“代碼是給人讀的，順便讓機(jī)器執(zhí)行。”

我覺(jué)得很有道理，雖然代碼是機(jī)器語(yǔ)言，但使用和調(diào)試還是由人來(lái)進(jìn)行的，所以仍然需要最大程度的滿(mǎn)足人性化的需求和設(shè)計(jì)思路。

看完那么多爛代碼的設(shè)計(jì)規(guī)范，其實(shí)就是圖一樂(lè)，我們也能從這些爛代碼規(guī)范中了解到想寫(xiě)出優(yōu)秀的的代碼應(yīng)該避免踩到哪些坑。下面是收集的一些資料，大家可以先收藏，沒(méi)事兒的時(shí)候看一看，爭(zhēng)取人人都能寫(xiě)得一手好代碼~