「編程不規範，同事兩行淚！」
【CSDN 編者按】編程江湖中一直盛傳著一個段子，那就是要問程序員最討厭哪 4 件事？那必須是：
寫注釋、寫文檔、別人不寫注釋、別人不寫文檔。
更甚者，在《流浪地球》形成刷屏之勢之後，仿其而出的「代碼千萬行，注釋第一行；編程不規範，同事兩行淚」在技術圈中開始盛傳，由此可見對於所有的程序員來說這是多麼痛苦的事情。
本文作者 —— 全棧開發者 Nitin Sharma 分享了編程的七宗罪，也許對你會有所啟發。
作者 | Nitin Sharma，全棧開發者
譯者 | 羅昭成
責編 | 沭七
出品 | CSDN（ID：CSDNnews）
以下為譯文：
還有什麼事情比自己動手去創造更有趣？看著你發明的東西慢慢地進入生活？我們人類，是萬物之主，是造物主。
但是在數字化時代，發明創造的方式發生了變化。現在，我們都創造數字化產品。我們建網站、寫軟體來滿足我們的需求。雖然我們創造不再依賴於我們的創造力，但是我們仍然可以與藝術家其名。
編程的世界非常地寬廣，涉及重多領域，我們有很多選擇。你可以選擇使用函數式編程，還是使用面向對象編程？你可以選擇做服務端還是客戶端？那麼，你心中已經有抉擇了嗎？下面，有 100 種編程語言，可以用來實現你的需求。
語言、框架、庫都在逐漸增多。你可以通過多種方式完成相同的代碼功能。雖然這些語言可能差別很大，但是大多數語言都遵循相同的思想。所以，他們也會出現相同的問題。
以下是編程七宗罪，你可以想辦法避免他們發生。雖然我不是基督教徒，但是我也喜歡定義七宗罪。
協作時不使用版本控制
上帝保佑，我們有版本控制工具。如我所說，如果我們沒有像 Git 這種版本管理工具，代碼的世界將變得異常艱難。版本控制讓我們在協作的時候，修改或移動變得非常簡單。
想像一下，我們坐在電腦前，手動檢查併合並文件，為不同的版本保存不同的文件夾。這樣做是非常低效的，並且很不可靠。幸運的是，我們有 Git 和其它版本控制工具，來幫我們完成這個事情。
我參與過沒有版本控制的項目，那簡直就是一場惡夢。
不使用合適的變數命名
我不知道為什麼，身邊總有一些人，使用很短/隨機的名稱來給變數命名。當你的項目只有 10-20 行代碼，或者只是代碼片段時，你可以使用這種方式進行命名，但是在大項目中，不要這麼做。不合適的命名，對可讀性和效率有致命的影響。
一個命名的簡單規則：你變數的名稱可以自解釋。當你看到它們的時候，就知道他們的用途。但是不要使用太長的名字來命名！保持命名簡短，並具有可讀性。
讓我們來找一找，你的代碼中用 a ， b， c 命名的代碼。
使用過多的依賴，不經思考直接升級
GitHub 上面有多少個開源項目? 已經多到我們數不清了。這些開源庫使開發者的工作變得更加容易，節約我們的時間。
但是使用過多的依賴庫會對整個項目帶來風險。依賴庫越多，就意味著編譯時間和運行時間的加長。我們應該在我們需要的地方添加對應的依賴庫，而不要為了使用它而使用它。
所以，在升級之前，我們需要經常去檢查依賴庫/插件的支持情況。我曾經有一次，升級了 React，而沒有去檢查它對其它庫的影響。到如今，我依然認為這是我生命中最嚴重的錯誤之一。
不自解釋的代碼
值得一提的是，沒有人想閱讀整個方法/文件來理解它是幹什麼用的。使用最少的代碼來實現功能，但是不要讓別人或者是以後的自己，討厭你自己寫的東西。
我們應該一直嘗試去寫自解釋的代碼。我們應該讓我們的代碼，在第一次被看到的時候，就知道它是幹什麼用的。要完成這樣的代碼，我們需要進行正確的代碼重構，統一的語法，適當的變數名稱。必要的時候，還要給代碼添加註釋。
當然，也不要過多地書寫注釋，你不需要通過注釋解釋每一行代碼。最好用 1-2 行注釋，寫清楚重要部分的概述或說明。
格式不一致
這個和第四點非常相近，格式不一致也會對可讀性和生產效率帶來巨大的影響。在項目中，選擇一個特定的命名規範並一直堅持下去，不要在中途改變它們。我個人更喜歡用大寫字母來命名文件，駝峰命名法來命名方法、變數等。但這些也會根據不同的語言而作出改變。
沒有比開發者格式化代碼更糟糕的事情。
此外，在代碼中，我們還需要使用相同的縮進格式。根據你的代碼樣式和選擇的語言，使用 2/4/8 個空格來做縮進。但無論你使用什麼樣的格式，請堅持在整個項目中一直使用。
不處理錯誤
畏懼它。逃避它。Bug 終會降臨！ —— 滅霸
（譯者註：指 Bug 如影隨形，不休不止，像詛咒一樣。）
事情是這樣的，無論你是多麼優秀的程序員，你的代碼都有可能會出現問題，除非你寫的是像如下的這種代碼：
這些錯誤有可能是因為 API 錯誤引起的，也有可能是超時，類型錯誤，空值，或者只有上帝知道的原因。通常，這些會讓你的代碼出現問題。
在不同的語言中，處理錯誤的方式有很大的差異。但是一般情況下，在訪問數據之前都需要判斷數據否為空。在我的經驗中，空指針比其它錯誤都多。
所以，在執行數據處理的相關需求時，建議將代碼放到 try-catch 中，並處理對應的異常，最後，不要忘記告訴用戶哪裡出現了問題。如果在用戶按下按鈕和按鍵的時候不給用戶反饋，用戶將不知道發生了什麼。給用戶錯誤提示，並告訴它下一步怎麼做。
時刻記住滅霸的話。
使用不當的數據類型/數據結構
在不同的語言中，數據類型要求不一樣，強類型語言非常嚴格，而弱類型可以隨意使用。強類型語言在編譯時就會告訴你錯誤，而其它語言需要在運行時，才能知道錯誤。
舉個例子，我們將數值存儲在整型/符點型/雙精度符點型的變數中，並且與存儲在字元串中的變數進行比較時，有的語言會進行自動類型轉換，然後進行比較，而有的語言並不會。
結語
編程七宗罪，讓人不爽。我們需要避免出現。
這個僅僅是在編程中出現的常見錯誤。你很難看到，一個程序員，在他的程序中出現這些問題。但這也正如聖經中的七宗罪一樣，不僅是這些問題。它們是原罪，可以組合成不同的錯誤。
你認為還有什麼錯誤需要加在這個列表裡面，在評論中寫出來，讓我知道。
Happy Coding!
原文地址：https://hackernoon.com/the-7-deadly-sins-of-programming-a7574efc639f
本文為 CSDN 翻譯，如需轉載，請註明來源出處。
熱 文推 薦
TAG:CSDN |