在本文中，我會(huì)列舉五條提高代碼可讀性的原則。這些原則是我在各種項(xiàng)目、團(tuán)隊(duì)和組織的實(shí)踐中總結(jié)出來的經(jīng)驗(yàn)。我希望大家可以從這篇文章中學(xué)到一些東西，從而提高代碼的可讀性。

>>>>

?太長不看版

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

重用會(huì)多次使用的內(nèi)容。

避免針對(duì)可讀性和可維護(hù)性制定一個(gè)通行的解決方案。

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

為你的代碼自動(dòng)化執(zhí)行一些規(guī)則和準(zhǔn)則。

就算你的團(tuán)隊(duì)只有你一個(gè)人，也要像是在多人團(tuán)隊(duì)中一樣編寫便于協(xié)作的代碼。

1. 重用會(huì)多次使用的內(nèi)容

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

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

但請(qǐng)注意，D.R.Y. 原則會(huì)讓你引入復(fù)雜性。因?yàn)榈阶詈?#xff0c;事物被重用的次數(shù)會(huì)越來越多。

當(dāng)你開始更改被多次重用的代碼時(shí)，針對(duì)這部分代碼編寫測試的重要性就會(huì)充分體現(xiàn)出來了。

2. 避免針對(duì)可讀性和可維護(hù)性制定通行的解決方案

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

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

通過多次迭代，你就可以在重用應(yīng)用程序很多部分的同時(shí)，仍然保持不錯(cuò)的可讀性和可維護(hù)性。

當(dāng)你在擁有許多開發(fā)團(tuán)隊(duì)的組織中工作時(shí)，你的團(tuán)隊(duì)可能會(huì)分為內(nèi)部人員和外部人員（例如自由職業(yè)者或顧問）。因此在這種情況下，人們會(huì)經(jīng)常在不同組織之間來回切換。

在這些場景中，可讀性和可維護(hù)性是成功的關(guān)鍵。讓那些很可能隨時(shí)離開團(tuán)隊(duì)的人員來制定通行的解決方案，并不是一個(gè)明智的選擇。

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

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

在為一款應(yīng)用程序構(gòu)建一些新功能時(shí)，你可能會(huì)在構(gòu)建前作詳細(xì)的規(guī)劃。

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

因?yàn)樾《未a更容易測試和維護(hù)。

想象一下，人們?cè)诂F(xiàn)實(shí)中搭建高層建筑時(shí)，也是從一個(gè)個(gè)較小的單元開始拼裝而成的，而不是一下子就把整幢大樓都造好，然后設(shè)法安裝到地基上。當(dāng)然了，例外也是有的。

大多數(shù)現(xiàn)代庫和框架都分成了一些較小的構(gòu)造塊，而不是打包成單個(gè)文件。像 Angular、React 和 Vue 這樣的 JavaScript 庫和框架都采用了組件的概念。我認(rèn)為他們的選擇并不是無意識(shí)的結(jié)果。

4. 為你的代碼自動(dòng)化執(zhí)行一些規(guī)則和準(zhǔn)則

想要編寫出可讀和可維護(hù)的代碼，一方面要關(guān)注的是代碼的架構(gòu)，另一方面則要關(guān)注代碼的樣式。

我想很多讀者都經(jīng)常會(huì)見到關(guān)于制表符或空格縮進(jìn)的討論。不過這里我不會(huì)討論這個(gè)話題。無論你在團(tuán)隊(duì)中使用的是哪種方案，請(qǐng)確保所有團(tuán)隊(duì)成員都遵守它就行了。

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

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

https://editorconfig.org/

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

• 縮進(jìn)樣式：制表符或空格

• 引號(hào)類型：單引號(hào)或雙引號(hào)

• 最大長度

• 字符集

• 還有更多……

下面是我在自己的一個(gè)項(xiàng)目中指定的配置：

# 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

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

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

不管怎樣，只要參與項(xiàng)目的所有人都遵循相同的規(guī)則和準(zhǔn)則，那么具體使用哪一種方案并不重要。

5. 就算只有你一個(gè)人，也要像在多人團(tuán)隊(duì)中一樣編寫代碼

最后一點(diǎn)也是非常重要的，那就是永遠(yuǎn)都像在團(tuán)隊(duì)中一樣編寫便于協(xié)作的代碼！

我可以想象，從未在團(tuán)隊(duì)中編寫過代碼的開發(fā)人員是很難理解這一條原則的。

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

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

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

不要擔(dān)心負(fù)面反饋！你只要關(guān)注那些可以讓你的代碼對(duì)其他人更具可讀性的反饋意見就行了。

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

小結(jié)

感謝大家的閱讀！希望你從本文中起碼能學(xué)到一點(diǎn)東西。

如果你對(duì)提高代碼可讀性的方法有任何補(bǔ)充，請(qǐng)隨時(shí)在評(píng)論中分享你的想法。

THE END—

編輯?∑Gemini

本文最初發(fā)布于 byrayray.dev 網(wǎng)站，經(jīng)原作者授權(quán)由 InfoQ 中文站翻譯并分享。

文章推薦

?頂級(jí)數(shù)學(xué)家如何做數(shù)學(xué)？當(dāng)代大師阿蘭·孔涅的探秘之旅

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

?數(shù)學(xué)竟然可以如此美麗

?數(shù)學(xué)與愛情

?微積分的發(fā)現(xiàn)是人類精神的最高勝利

?父子同獲諾貝爾獎(jiǎng)什么的：細(xì)數(shù)那些從事物理學(xué)和數(shù)學(xué)的一家子

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。