代碼千萬(wàn)行，注釋第一行；編程不規(guī)范，同事兩行淚。本文分享了編程的七宗罪，也許對(duì)你會(huì)有所啟發(fā)。

編程江湖中一直盛傳著一個(gè)段子，那就是要問(wèn)程序員最討厭哪 4 件事？那必須是：

寫注釋、寫文檔、別人不寫注釋、別人不寫文檔。

更甚者，在《流浪地球》形成刷屏之勢(shì)之后，仿其而出的 “代碼千萬(wàn)行，注釋第一行；編程不規(guī)范，同事兩行淚” 在技術(shù)圈中開(kāi)始盛傳，由此可見(jiàn)對(duì)于所有的程序員來(lái)說(shuō)這是多么痛苦的事情。

本文作者 —— 全棧開(kāi)發(fā)者 Nitin Sharma 分享了編程的七宗罪，也許對(duì)你會(huì)有所啟發(fā)。

以下為譯文：

還有什么事情比自己動(dòng)手去創(chuàng)造更有趣？看著你發(fā)明的東西慢慢地進(jìn)入生活？我們?nèi)祟悾侨f(wàn)物之主，是造物主。

但是在數(shù)字化時(shí)代，發(fā)明創(chuàng)造的方式發(fā)生了變化。現(xiàn)在，我們都創(chuàng)造數(shù)字化產(chǎn)品。我們建網(wǎng)站、寫軟件來(lái)滿足我們的需求。雖然我們創(chuàng)造不再依賴于我們的創(chuàng)造力，但是我們?nèi)匀豢梢耘c藝術(shù)家其名。

編程的世界非常地寬廣，涉及重多領(lǐng)域，我們有很多選擇。你可以選擇使用函數(shù)式編程，還是使用面向?qū)ο缶幊蹋磕憧梢赃x擇做服務(wù)端還是客戶端？那么，你心中已經(jīng)有抉擇了嗎？下面，有 100 種編程語(yǔ)言，可以用來(lái)實(shí)現(xiàn)你的需求。

語(yǔ)言、框架、庫(kù)都在逐漸增多。你可以通過(guò)多種方式完成相同的代碼功能。雖然這些語(yǔ)言可能差別很大，但是大多數(shù)語(yǔ)言都遵循相同的思想。所以，他們也會(huì)出現(xiàn)相同的問(wèn)題。

以下是編程七宗罪，你可以想辦法避免他們發(fā)生。雖然我不是基督教徒，但是我也喜歡定義七宗罪。

01. 協(xié)作時(shí)不使用版本控制

上帝保佑，我們有版本控制工具。如我所說(shuō)，如果我們沒(méi)有像 Git 這種版本管理工具，代碼的世界將變得異常艱難。版本控制讓我們?cè)趨f(xié)作的時(shí)候，修改或移動(dòng)變得非常簡(jiǎn)單。

想像一下，我們坐在電腦前，手動(dòng)檢查并合并文件，為不同的版本保存不同的文件夾。這樣做是非常低效的，并且很不可靠。幸運(yùn)的是，我們有 Git 和其它版本控制工具，來(lái)幫我們完成這個(gè)事情。

我參與過(guò)沒(méi)有版本控制的項(xiàng)目，那簡(jiǎn)直就是一場(chǎng)惡夢(mèng)。

02. 不使用合適的變量命名

我不知道為什么，身邊總有一些人，使用很短 / 隨機(jī)的名稱來(lái)給變量命名。當(dāng)你的項(xiàng)目只有 10-20 行代碼，或者只是代碼片段時(shí)，你可以使用這種方式進(jìn)行命名，但是在大項(xiàng)目中，不要這么做。不合適的命名，對(duì)可讀性和效率有致命的影響。

一個(gè)命名的簡(jiǎn)單規(guī)則：你變量的名稱可以自解釋。當(dāng)你看到它們的時(shí)候，就知道他們的用途。但是不要使用太長(zhǎng)的名字來(lái)命名！保持命名簡(jiǎn)短，并具有可讀性。

讓我們來(lái)找一找，你的代碼中用 a ， b， c 命名的代碼。

03. 使用過(guò)多的依賴，不經(jīng)思考直接升級(jí)

GitHub 上面有多少個(gè)開(kāi)源項(xiàng)目？已經(jīng)多到我們數(shù)不清了。這些開(kāi)源庫(kù)使開(kāi)發(fā)者的工作變得更加容易，節(jié)約我們的時(shí)間。

但是使用過(guò)多的依賴庫(kù)會(huì)對(duì)整個(gè)項(xiàng)目帶來(lái)風(fēng)險(xiǎn)。依賴庫(kù)越多，就意味著編譯時(shí)間和運(yùn)行時(shí)間的加長(zhǎng)。我們應(yīng)該在我們需要的地方添加對(duì)應(yīng)的依賴庫(kù)，而不要為了使用它而使用它。

所以，在升級(jí)之前，我們需要經(jīng)常去檢查依賴庫(kù) / 插件的支持情況。我曾經(jīng)有一次，升級(jí)了 React，而沒(méi)有去檢查它對(duì)其它庫(kù)的影響。到如今，我依然認(rèn)為這是我生命中最嚴(yán)重的錯(cuò)誤之一。

04. 不自解釋的代碼

值得一提的是，沒(méi)有人想閱讀整個(gè)方法 / 文件來(lái)理解它是干什么用的。使用最少的代碼來(lái)實(shí)現(xiàn)功能，但是不要讓別人或者是以后的自己，討厭你自己寫的東西。

我們應(yīng)該一直嘗試去寫自解釋的代碼。我們應(yīng)該讓我們的代碼，在第一次被看到的時(shí)候，就知道它是干什么用的。要完成這樣的代碼，我們需要進(jìn)行正確的代碼重構(gòu)，統(tǒng)一的語(yǔ)法，適當(dāng)?shù)淖兞棵Q。必要的時(shí)候，還要給代碼添加注釋。

當(dāng)然，也不要過(guò)多地書(shū)寫注釋，你不需要通過(guò)注釋解釋每一行代碼。最好用 1-2 行注釋，寫清楚重要部分的概述或說(shuō)明。

05. 格式不一致

這個(gè)和第四點(diǎn)非常相近，格式不一致也會(huì)對(duì)可讀性和生產(chǎn)效率帶來(lái)巨大的影響。在項(xiàng)目中，選擇一個(gè)特定的命名規(guī)范并一直堅(jiān)持下去，不要在中途改變它們。我個(gè)人更喜歡用大寫字母來(lái)命名文件，駝峰命名法來(lái)命名方法、變量等。但這些也會(huì)根據(jù)不同的語(yǔ)言而作出改變。

沒(méi)有比開(kāi)發(fā)者格式化代碼更糟糕的事情。

此外，在代碼中，我們還需要使用相同的縮進(jìn)格式。根據(jù)你的代碼樣式和選擇的語(yǔ)言，使用 2/4/8 個(gè)空格來(lái)做縮進(jìn)。但無(wú)論你使用什么樣的格式，請(qǐng)堅(jiān)持在整個(gè)項(xiàng)目中一直使用。

06. 不處理錯(cuò)誤

畏懼它。逃避它。Bug 終會(huì)降臨！ —— 滅霸

（譯者注：指 Bug 如影隨形，不休不止，像詛咒一樣。）

事情是這樣的，無(wú)論你是多么優(yōu)秀的程序員，你的代碼都有可能會(huì)出現(xiàn)問(wèn)題，除非你寫的是像如下的這種代碼：

console.log("Yey")printf("Wow")

這些錯(cuò)誤有可能是因?yàn)?API 錯(cuò)誤引起的，也有可能是超時(shí)，類型錯(cuò)誤，空值，或者只有上帝知道的原因。通常，這些會(huì)讓你的代碼出現(xiàn)問(wèn)題。

在不同的語(yǔ)言中，處理錯(cuò)誤的方式有很大的差異。但是一般情況下，在訪問(wèn)數(shù)據(jù)之前都需要判斷數(shù)據(jù)否為空。在我的經(jīng)驗(yàn)中，空指針比其它錯(cuò)誤都多。

所以，在執(zhí)行數(shù)據(jù)處理的相關(guān)需求時(shí)，建議將代碼放到 try-catch 中，并處理對(duì)應(yīng)的異常，最后，不要忘記告訴用戶哪里出現(xiàn)了問(wèn)題。如果在用戶按下按鈕和按鍵的時(shí)候不給用戶反饋，用戶將不知道發(fā)生了什么。給用戶錯(cuò)誤提示，并告訴它下一步怎么做。

時(shí)刻記住滅霸的話。

07. 使用不當(dāng)?shù)臄?shù)據(jù)類型 / 數(shù)據(jù)結(jié)構(gòu)

在不同的語(yǔ)言中，數(shù)據(jù)類型要求不一樣，強(qiáng)類型語(yǔ)言非常嚴(yán)格，而弱類型可以隨意使用。強(qiáng)類型語(yǔ)言在編譯時(shí)就會(huì)告訴你錯(cuò)誤，而其它語(yǔ)言需要在運(yùn)行時(shí)，才能知道錯(cuò)誤。

舉個(gè)例子，我們將數(shù)值存儲(chǔ)在整型 / 符點(diǎn)型 / 雙精度符點(diǎn)型的變量中，并且與存儲(chǔ)在字符串中的變量進(jìn)行比較時(shí)，有的語(yǔ)言會(huì)進(jìn)行自動(dòng)類型轉(zhuǎn)換，然后進(jìn)行比較，而有的語(yǔ)言并不會(huì)。

結(jié)語(yǔ)

編程七宗罪，讓人不爽。我們需要避免出現(xiàn)。

這個(gè)僅僅是在編程中出現(xiàn)的常見(jiàn)錯(cuò)誤。你很難看到，一個(gè)程序員，在他的程序中出現(xiàn)這些問(wèn)題。但這也正如圣經(jīng)中的七宗罪一樣，不僅是這些問(wèn)題。它們是原罪，可以組合成不同的錯(cuò)誤。

你認(rèn)為還有什么錯(cuò)誤需要加在這個(gè)列表里面，在評(píng)論中寫出來(lái)，讓我知道。

Happy Coding!