良好的編碼習慣 —— 5 個提升代碼質量的技巧

• 原文地址：Good Coding Practices – Five Tips to Enhance Code Quality
• 原文做者：Jay
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：NeoyeElf
• 校對者：dandyxu，allenlongbaobao

良好的編碼習慣 —— 5 個提升代碼質量的技巧

良好的編碼習慣像黑夜中的一盞明燈，指引着迷路的開發者安全靠岸。良好的代碼是可預測的，是易於調試、擴展和測試的。

良好的編碼習慣可以提升你同事的工做效率，同時讓你的代碼庫從總體上給人一種愉快的閱讀體驗。

接下來我要和大家分享的是 5 個通用的良好編碼習慣，它們能提升你代碼的可讀性，可擴展性和總體質量。越快理解和運用這些準則，你的收益就越大。

讓咱們開始吧。

爲何要有良好的編碼習慣？

學習和運用良好的編碼習慣就像投資那些你知道必定會成倍增加的股票。換句話說，你只要如今作一次性的投資，在接下來的幾年甚至幾個月的收益和回報，將會遠遠超過你如今的投入。

處於職業生涯任何階段的開發者都會受益於應用和學習良好的編碼習慣。就像我上面所說，你越早開始使用它們，你的收益便越大。如今即是最好的時機來學習和將良好的編碼習慣應用於你如今的項目。

我提出這些觀點，旨在它們可以互相支撐，且不管是做爲單獨的建議仍是組合起來都是合理的。

1. 簡潔地給方法和變量命名

當給類、變量和方法命名時，咱們很容易衝動地按照本身的方式給它們命名。特別是當你以爲這一切都很合理時。試着幾個月以後再回頭看看那些代碼，看看它們是否依舊合理。若是是，那麼頗有多是你當時明智地命名了你的變量和方法。

方法名相似文章中的標題和句子。

所以，當給方法命名時，要可以準確歸納方法的內容。若是方法名變得太長或模糊，那麼表示該方法作了太多的事情。

方法中的內容組成了方法名。

當你閱讀一篇文章時，你以爲最突出的是什麼？一般，最突出的是標題。在程序中，關鍵方法就像標題。當你爲高中或大學散文寫投稿文章時，你是否只是隨便瞎寫幾句，而後不假思索地寫完標題？

一個簡單直觀的方法名賽過千言萬語。

固然，句子中單詞的選擇以及如何將它們組合在一塊兒也很重要。這就是爲何咱們也須要特地地給咱們的變量命名。大多數狀況下，在查看代碼邏輯以前，人們會試圖經過閱讀每一行中的變量名來對代碼實現細節的有一個總體把握。

確保方法和變量名稱都是清晰明瞭的，且準確地描述了正在發生的事情。想象一下，若是你指引給一個遊客錯誤的方向，他/她會多麼生氣和困惑。你正在爲下一個前來閱讀你代碼的程序員指引道路。

2. 儘量減小使用全局變量

無論使用哪一種語言，你可能在編程中常常聽到這種說法。人們只會說使用全局變量很差，而不去解釋爲何很差。那麼讓我來告訴你爲何應該儘量地減小和避免全局變量。

全局變量會形成困惑，由於程序中的任何地方均可以訪問到它們。

若是全局變量同時也是可變的，則會增長人們的困惑。若是你聲明瞭一個變量，那麼極可能你只是想在本身的代碼中去使用它。你猜猜接下來會發生什麼？

這裏是一個用 JavaScript 語言編寫的基礎示例，但不管你使用的是哪一種編程語言，下面這段代碼都應該很容易理解。

var GLOBAL_NUMBER = 5;
function add(num1) {
return num1 + GLOBAL_NUMBER;
}
複製代碼

對於這個函數，即便咱們傳入 num1 = 3，咱們也沒法肯定該方法是否會返回 8，由於該程序的其餘部分也許已經修改了 GLOBAL_NUMBER 的值。

這增長了程序產生反作用的可能性，特別是當咱們使用多線程編程時。更糟糕的是，程序的複雜性與代碼量的大小成正比。

在 100 行的代碼中使用單個全局變量是可管理的。可是想象一下，若是這個項目後來演變成一個擁有 10000 行代碼的項目。那麼項目中有不少地方均可以修改這個變量。並且，到目前爲止，代碼中可能還添加了其餘的全局變量。

如今維護代碼簡直就是一個噩夢。

若是可能的話，找到消除全局變量的方法。全局變量增長了每一個開發人員的工做難度。

3. 編寫可預測的代碼

若是你關注個人博客，你可能會發現我喜歡純函數。特別地，若是你是初學者，我懇請你嘗試編寫乾淨的代碼。讓我來告訴你編寫代碼中 4 個須要遵照的點。

避免狀態共享（emm...全局變量）。保持函數乾淨。換句話說，函數、類、子程序都應該只有單一的職責。

若是你的工做是煮米飯，那就煮米飯，不要作其餘的事情，以避免讓你的同事感到困惑。不要作不應你作的事情。

具備可預測結果的代碼就像一臺自動售貨機。你把錢放進去，按下可樂的按鈕。你知道你的錢能夠換一罐可樂。對於編碼，這條規則也適用。使編碼結果可預測。一個良好的編碼習慣是編寫可預測結果的代碼。

想象一下，若是你將錢放入自動售貨機，按下可樂按鈕，但相反，自動售貨機給你了芬達。除非你喜歡驚喜，或者你不在意喝什麼，不然你是確定不會感到快樂的。

無一例外，開發人員並不喜歡由糟糕代碼的反作用帶來的驚喜。

讓咱們來看一個很簡單的示例。

function add(num1, num2) {
return num1 + num2;
}
複製代碼

上面這個簡單的 add 函數是純粹的。它產生可預測的結果。不管你在什麼環境使用它，不管任何全局變量，若是你輸入 1 和 2，你老是會獲得 3。

// This will never equal a value 
// other than three
add(1, 2);
複製代碼

4. 編寫可重用的代碼

我嘗試模塊化編碼，這樣一來我就能夠簡單地導入該模塊，而沒必要重寫它。這比從新發明輪子要好，若是你能夠保持模塊簡潔，這樣一來便會減小 bugs 和反作用。

最重要的是，我想讓你明白爲何咱們喜歡堅持這些原則。

當能夠將代碼移植到另外一個開發環境並沒有縫集成到 Tweet 時，代碼即是可重用的。

請記住，你並非(或者至少不該該是)惟一編寫和維護該代碼庫的人。基於第1、第二和第三點，可使咱們作到第四點，即編寫可重用的代碼。換句話說，步驟 1-3 幫助咱們編寫可重用的代碼。讓咱們回顧複習一下爲何步驟 1-3 能幫助開發人員編寫可重用代碼。

• 簡單明瞭的方法和變量名使代碼更容易被其餘開發人員所接受。
• 可重用的代碼不該該依賴於全局狀態。使用了依賴庫的代碼一般被歸類爲難以重用的代碼。
• 可重用的代碼應該產生不依賴於可變狀態的一致結果。

當寫代碼時，嘗試問本身：「我可否（或我是否想要）在其餘項目中重用這塊代碼？」。這會幫助你寫出可重用的代碼，即更加有價值的代碼。

5. 寫單元測試

你可能已經聽過不少次了，這是由於單元測試使代碼更加成熟和健壯。因爲項目時間限制，單元測試成爲了避免受歡迎的良好編碼習慣之一。項目經理和客戶但願馬上獲得結果。

擁有單元測試的代碼就像一棵中國竹子。在開始的時候成效並不明顯，但只要你有耐心，在某個適當的時候，收益是顯而易見且十分值得的！

在最初的四年裏，中國竹子生長受限。和任何其餘植物同樣，它須要培養。在第五年，它在僅僅 6 周內就長了 80 英尺。

雖然單元測試能帶來的收益並不須要花那麼長的時間，可是一般狀況下，你和你項目經理的耐心都將受到考驗。固然，若是大家願意花時間去編寫這些單元測試並關注代碼質量，代碼的質量和健壯性都會獲得巨大改進。全部這些努力最終都將轉化爲更好的用戶體驗和擁有最小反作用的更容易擴展的代碼。

若是你不被容許在你的工做代碼中編寫單元測試，那麼嘗試養成在你的我的項目中編寫單元測試的習慣。許多公司看到了編寫單元測試的價值，這是一項很是有用的技能。

比這項技能更重要的是，單元測試可以擴寬開發者的視野，從全局考慮問題，檢查全部可能的狀況。

考慮這些狀況的可能性，從而權衡利弊，添加適當數量的有效檢查用例。作各類假設，而後從新設計編碼。

全部的這些心血、汗水和眼淚最終將匯聚成優美的、通過測試的純粹健壯的代碼。它可重用，可預測，並可能會很好地服務於你將來的工做。

閱讀本文所獲取的知識至少能夠幫助你成爲一名成熟的程序員。

完善清單

若是你有其餘更好的編碼習慣想讓我加入這份清單中，或者你以爲清單中遺漏了一個重要的點，請在下方評論留言。我會盡快將您的意見加入這份清單中。

感想您的閱讀，happy coding!

關於做者 Jay

我是一個程序員，目前住在韓國首爾。我建立這個博客是爲了將我已掌握和正在學習的知識用寫文章的形式表達出來，以做知識積累，同時也但願可以幫助構建更廣大的社區。我熱衷於數據結構和算法，專精於後端和數據庫。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。