「編程不規範 親人淚兩行」

閱讀本文大概須要 4.2 分鐘。

 

做者：Nitin Sharma

譯者：羅昭成

出品：CSDN（ID：CSDNnews）

【筆者按】編程江湖中一直盛傳着一個段子，那就是要問程序員最討厭哪 4 件事？那必須是：

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

更甚者，在《流浪地球》造成刷屏之勢以後，仿其而出的「代碼千萬行，註釋第一行；編程不規範，同事兩行淚」在技術圈中開始盛傳，因而可知對於全部的程序員來講這是多麼痛苦的事情。

 

如下爲譯文：

還有什麼事情比本身動手去創造更有趣？看着你發明的東西慢慢地進入生活？咱們人類，是萬物之主，是造物主。

可是在數字化時代，發明創造的方式發生了變化。如今，咱們都創造數字化產品。咱們建網站、寫軟件來知足咱們的需求。雖然咱們創造再也不依賴於咱們的創造力，可是咱們仍然能夠與藝術家其名。

編程的世界很是地寬廣，涉及重多領域，咱們有不少選擇。你能夠選擇使用函數式編程，仍是使用面向對象編程？你能夠選擇作服務端仍是客戶端？那麼，你心中已經有抉擇了嗎？下面，有 100 種編程語言，能夠用來實現你的需求。

語言、框架、庫都在逐漸增多。你能夠經過多種方式完成相同的代碼功能。雖然這些語言可能差異很大，可是大多數語言都遵循相同的思想。因此，他們也會出現相同的問題。

如下是編程七宗罪，你能夠想辦法避免他們發生。雖然我不是基督教徒，可是我也喜歡定義七宗罪。

 

一、協做時不使用版本控制

 

上帝保佑，咱們有版本控制工具。如我所說，若是咱們沒有像 Git 這種版本管理工具，代碼的世界將變得異常艱難。版本控制讓咱們在協做的時候，修改或移動變得很是簡單。

想像一下，咱們坐在電腦前，手動檢查併合並文件，爲不一樣的版本保存不一樣的文件夾。這樣作是很是低效的，而且很不可靠。幸運的是，咱們有 Git 和其它版本控制工具，來幫咱們完成這個事情。

我參與過沒有版本控制的項目，那簡直就是一場惡夢。

 

二、不使用合適的變量命名

 

我不知道爲何，身邊總有一些人，使用很短/隨機的名稱來給變量命名。當你的項目只有 10-20 行代碼，或者只是代碼片斷時，你可使用這種方式進行命名，可是在大項目中，不要這麼作。不合適的命名，對可讀性和效率有致命的影響。

一個命名的簡單規則：你變量的名稱能夠自解釋。當你看到它們的時候，就知道他們的用途。可是不要使用太長的名字來命名！保持命名簡短，並具備可讀性。

讓咱們來找一找，你的代碼中用 a ， b， c 命名的代碼。

 

三、使用過多的依賴，不經思考直接升級

 

GitHub 上面有多少個開源項目? 已經多到咱們數不清了。這些開源庫使開發者的工做變得更加容易，節約咱們的時間。

可是使用過多的依賴庫會對整個項目帶來風險。依賴庫越多，就意味着編譯時間和運行時間的加長。咱們應該在咱們須要的地方添加對應的依賴庫，而不要爲了使用它而使用它。

因此，在升級以前，咱們須要常常去檢查依賴庫/插件的支持狀況。我曾經有一次，升級了 React，而沒有去檢查它對其它庫的影響。到現在，我依然認爲這是我生命中最嚴重的錯誤之一。

 

四、不自解釋的代碼

 

值得一提的是，沒有人想閱讀整個方法/文件來理解它是幹什麼用的。使用最少的代碼來實現功能，可是不要讓別人或者是之後的本身，討厭你本身寫的東西。

咱們應該一直嘗試去寫自解釋的代碼。咱們應該讓咱們的代碼，在第一次被看到的時候，就知道它是幹什麼用的。要完成這樣的代碼，咱們須要進行正確的代碼重構，統一的語法，適當的變量名稱。必要的時候，還要給代碼添加註釋。

固然，也不要過多地書寫註釋，你不須要經過註釋解釋每一行代碼。最好用 1-2 行註釋，寫清楚重要部分的概述或說明。

 

五、格式不一致

 

這個和第四點很是相近，格式不一致也會對可讀性和生產效率帶來巨大的影響。在項目中，選擇一個特定的命名規範並一直堅持下去，不要在中途改變它們。

我我的更喜歡用大寫字母來命名文件，駝峯命名法來命名方法、變量等。但這些也會根據不一樣的語言而做出改變。

沒有比開發者格式化代碼更糟糕的事情。

此外，在代碼中，咱們還須要使用相同的縮進格式。根據你的代碼樣式和選擇的語言，使用 2/4/8 個空格來作縮進。但不管你使用什麼樣的格式，項目中一直使用。

 

六、不處理錯誤

 

畏懼它。逃避它。Bug 終會降臨！ —— 滅霸

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

事情是這樣的，不管你是多麼優秀的程序員，你的代碼都有可能會出現問題，除非你寫的是像以下的這種代碼：

這些錯誤有多是由於 API 錯誤引發的，也有多是超時，類型錯誤，空值，或者只有上帝知道的緣由。一般，這些會讓你的代碼出現問題。

在不一樣的語言中，處理錯誤的方式有很大的差別。可是通常狀況下，在訪問數據以前都須要判斷數據否爲空。在個人經驗中，空指針比其它錯誤都多。

因此，在執行數據處理的相關需求時，建議將代碼放到 try-catch 中，並處理對應的異常，最後，不要忘記告訴用戶哪裏出現了問題。若是在用戶按下按鈕和按鍵的時候不給用戶反饋，用戶將不知道發生了什麼。給用戶錯誤提示，並告訴它下一步怎麼作。

時刻記住滅霸的話。

 

七、使用不當的數據類型/數據結構

 

在不一樣的語言中，數據類型要求不同，強類型語言很是嚴格，而弱類型能夠隨意使用。強類型語言在編譯時就會告訴你錯誤，而其它語言須要在運行時，才能知道錯誤。

舉個例子，咱們將數值存儲在整型/符點型/雙精度符點型的變量中，而且與存儲在字符串中的變量進行比較時，有的語言會進行自動類型轉換，而後進行比較，而有的語言並不會。

 

 

八、結語

 

編程七宗罪，讓人不爽。咱們須要避免出現。

這個僅僅是在編程中出現的常見錯誤。你很難看到，一個程序員，在他的程序中出現這些問題。但這也正如聖經中的七宗罪同樣，不只是這些問題。它們是原罪，能夠組合成不一樣的錯誤。

你認爲還有什麼錯誤須要加在這個列表裏面，在評論中寫出來，讓我知道。

Happy Coding!

 

原文連接：

https://mp.weixin.qq.com/s/BIlWx7w4Lhx-vprIBfdeWg

 

 

往期精彩回顧

 

程序員接私活的7大平臺利器

爲什麼IntelliJ IDEA比Eclipse更好

巧用這19條MySQL優化，效率至少提升3倍

想囤書的趕忙看過來（精選書單）

IDEA必定要懂的32條快捷鍵

世上最污技術解讀，我居然秒懂了

一千行MySQL詳細學習筆記

七點建議助您寫出優雅的Java代碼

歡迎關注個人公衆號「程序員的成長之路」，閱讀更多精彩！