在本文中，我會列舉五條提高代碼可讀性的原則。這些原則是我在各種項目、團隊和組織的實踐中總結出來的經驗。我希望大家可以從這篇文章中學到一些東西，從而提高代碼的可讀性。

>>>>

?太長不看版

總有人不喜歡從頭到尾看完全文，而是想趕快看完重點，這里為此準備了太長不看版：

重用會多次使用的內容。

避免針對可讀性和可維護性制定一個通行的解決方案。

盡可能減小模塊、類或組件的大小。

為你的代碼自動化執行一些規則和準則。

就算你的團隊只有你一個人，也要像是在多人團隊中一樣編寫便于協作的代碼。

1. 重用會多次使用的內容

大多數開發人員都知道 D.R.Y. 是什么意思（避免重復代碼）。D.R.Y. 可以幫助你預防代碼重復的問題。

為什么一個函數要寫一遍又一遍呢？你應該只編寫一次，然后在需要它的各個位置重復使用它。而且如果你需要更改它的代碼，就只需要改動一處位置就可以了，用不著把修改好錯誤的版本復制粘貼到各個地方。

但請注意，D.R.Y. 原則會讓你引入復雜性。因為到最后，事物被重用的次數會越來越多。

當你開始更改被多次重用的代碼時，針對這部分代碼編寫測試的重要性就會充分體現出來了。

2. 避免針對可讀性和可維護性制定通行的解決方案

可重用性、可讀性和可維護性彼此之間既是朋友也是敵人。當你開始在自己的代碼中踐行 D.R.Y. 原則，你就會引入復雜性。當你引入復雜性時，可讀性水平可能就會下降了。

因此，在構建功能時不要想著先做一個通行的解決方案。從簡單入手是最好的！第一次嘗試肯定沒法做到盡善盡美。

通過多次迭代，你就可以在重用應用程序很多部分的同時，仍然保持不錯的可讀性和可維護性。

當你在擁有許多開發團隊的組織中工作時，你的團隊可能會分為內部人員和外部人員（例如自由職業者或顧問）。因此在這種情況下，人們會經常在不同組織之間來回切換。

在這些場景中，可讀性和可維護性是成功的關鍵。讓那些很可能隨時離開團隊的人員來制定通行的解決方案，并不是一個明智的選擇。

在某些情況下，你的確需要通行方案，但這些方案必須做到很容易閱讀和維護。

3. 盡可能減小模塊、類或組件的大小

在為一款應用程序構建一些新功能時，你可能會在構建前作詳細的規劃。

最佳的解決方案肯定是能拆分成許多較小的模塊、類或組件的。你想知道為什么嗎？

因為小段代碼更容易測試和維護。

想象一下，人們在現實中搭建高層建筑時，也是從一個個較小的單元開始拼裝而成的，而不是一下子就把整幢大樓都造好，然后設法安裝到地基上。當然了，例外也是有的。

大多數現代庫和框架都分成了一些較小的構造塊，而不是打包成單個文件。像 Angular、React 和 Vue 這樣的 JavaScript 庫和框架都采用了組件的概念。我認為他們的選擇并不是無意識的結果。

4. 為你的代碼自動化執行一些規則和準則

想要編寫出可讀和可維護的代碼，一方面要關注的是代碼的架構，另一方面則要關注代碼的樣式。

我想很多讀者都經常會見到關于制表符或空格縮進的討論。不過這里我不會討論這個話題。無論你在團隊中使用的是哪種方案，請確保所有團隊成員都遵守它就行了。

最好的解決方案是，盡可能讓這些代碼樣式規則和準則自動化。許多 IDE 都集成了這種功能，或者可以通過插件安裝。

最簡單的一種，也是支持多種語言和代碼編輯器的方案是 editorconfig。只要添加一個.editorconfig，就可以應用這些規則。

https://editorconfig.org/

你可以在這些文件中為你的項目調整許多設置。你也可以指定全局設置方案，或者為特定的語言指定設置。例如：

• 縮進樣式：制表符或空格

• 引號類型：單引號或雙引號

• 最大長度

• 字符集

• 還有更多……

下面是我在自己的一個項目中指定的配置：

# Editor configuration, see https://editorconfig.org root = true [*] charset = utf-8 indent_style = space indent_size = 2 insert_final_newline = true trim_trailing_whitespace = true [*.ts] quote_type = single [*.md] max_line_length = off trim_trailing_whitespace = false

網絡上還有許多適用于某些特定語言的工具。對于 JavaScript 來說，我喜歡使用 Prettier，但你可能希望換一些不一樣的工具。

https://medium.com/better-programming/eslint-vs-prettier-57882d0fec1d

不管怎樣，只要參與項目的所有人都遵循相同的規則和準則，那么具體使用哪一種方案并不重要。

5. 就算只有你一個人，也要像在多人團隊中一樣編寫代碼

最后一點也是非常重要的，那就是永遠都像在團隊中一樣編寫便于協作的代碼！

我可以想象，從未在團隊中編寫過代碼的開發人員是很難理解這一條原則的。

可是如果你在一個人編寫項目，就會很容易寫出來很多只有你自己才能理解的代碼（例如編寫模糊不清的變量名、使用 2-3 個字符的變量名等等）。

應該試著像在團隊中一樣編寫能方便他人理解的代碼。想象一下，這就是說你的代碼應該足夠清晰明了，讓其他人可以輕松理解。

你可以問一問朋友，或者在開發者社區中通過 Twitter 找什么人過來幫你檢查代碼的可讀性，這是很簡單的測試方法。我可以保證，你會得到自己意想不到的反饋。

不要擔心負面反饋！你只要關注那些可以讓你的代碼對其他人更具可讀性的反饋意見就行了。

你應該知道，可讀代碼與讀起來略吃力的代碼之間并沒有很清晰的界限，不同人會在這個問題上有不同的看法。如果有人告訴你你的代碼很難讀，那也不要難過！你應該感謝對方的反饋意見。

小結

感謝大家的閱讀！希望你從本文中起碼能學到一點東西。

如果你對提高代碼可讀性的方法有任何補充，請隨時在評論中分享你的想法。

THE END—

編輯?∑Gemini

本文最初發布于 byrayray.dev 網站，經原作者授權由 InfoQ 中文站翻譯并分享。

文章推薦

?頂級數學家如何做數學？當代大師阿蘭·孔涅的探秘之旅

?耶魯大學教授給研究生的一些忠告

?數學竟然可以如此美麗

?數學與愛情

?微積分的發現是人類精神的最高勝利

?父子同獲諾貝爾獎什么的：細數那些從事物理學和數學的一家子

總結

以上是生活随笔為你收集整理的改善代码可读性的5种方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。