良好的編碼習慣 —— 5 個提高程式碼質量的技巧

再也不悍跳的阿哲發表於2018-03-29

良好的編碼習慣 —— 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-3 幫助我們編寫可重用的程式碼。讓我們回顧複習一下為什麼步驟 1-3 能幫助開發人員編寫可重用程式碼。

  • 簡單明瞭的方法和變數名使程式碼更容易被其他開發人員所接受。
  • 可重用的程式碼不應該依賴於全域性狀態。使用了依賴庫的程式碼通常被歸類為難以重用的程式碼。
  • 可重用的程式碼應該產生不依賴於可變狀態的一致結果。

當寫程式碼時，嘗試問自己：“我能否（或我是否想要）在其他專案中重用這塊程式碼？”。這會幫助你寫出可重用的程式碼，即更加有價值的程式碼。

5. 寫單元測試

你可能已經聽過很多次了，這是因為單元測試使程式碼更加成熟和健壯。由於專案時間限制，單元測試成為了不受歡迎的良好編碼習慣之一。專案經理和客戶希望立刻得到結果。

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

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

擁有單元測試的程式碼就像竹子

雖然單元測試能帶來的收益並不需要花那麼長的時間，但是通常情況下，你和你專案經理的耐心都將受到考驗。當然，如果你們願意花時間去編寫這些單元測試並關注程式碼質量，程式碼的質量和健壯性都會得到巨大改進。所有這些努力最終都將轉化為更好的使用者體驗和擁有最小副作用的更容易擴充套件的程式碼。

如果你不被允許在你的工作程式碼中編寫單元測試，那麼嘗試養成在你的個人專案中編寫單元測試的習慣。許多公司看到了編寫單元測試的價值，這是一項非常有用的技能。

比這項技能更重要的是，單元測試能夠擴寬開發者的視野，從全域性考慮問題，檢查所有可能的情況。

考慮這些情況的可能性，從而權衡利弊，新增適當數量的有效檢查用例。做各種假設，然後重新設計編碼。

所有的這些心血、汗水和眼淚最終將匯聚成優美的、經過測試的純粹健壯的程式碼。它可重用，可預測，並可能會很好地服務於你未來的工作。

閱讀本文所獲取的知識至少可以幫助你成為一名成熟的程式設計師。

完善清單

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

感想您的閱讀，happy coding!

關於作者 Jay

我是一個程式設計師，目前住在韓國首爾。我建立這個部落格是為了將我已掌握和正在學習的知識用寫文章的形式表達出來，以作知識積累，同時也希望能夠幫助構建更廣大的社群。我熱衷於資料結構和演算法，專精於後端和資料庫。

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

相關文章