5 個改善代碼可讀性的方法
總有人不喜歡從頭到尾看完全文，而是想趕快看完重點，這里為此準(zhǔn)備了太長不看版：
重用會多次使用的內(nèi)容。
避免針對可讀性和可維護性制定一個通行的解決方案。
盡可能減小模塊、類或組件的大小。
為你的代碼自動化執(zhí)行一些規(guī)則和準(zhǔn)則。
就算你的團隊只有你一個人，也要像是在多人團隊中一樣編寫便于協(xié)作的代碼。
大多數(shù)開發(fā)人員都知道 D.R.Y. 是什么意思（避免重復(fù)代碼）。D.R.Y. 可以幫助你預(yù)防代碼重復(fù)的問題。
為什么一個函數(shù)要寫一遍又一遍呢？你應(yīng)該只編寫一次，然后在需要它的各個位置重復(fù)使用它。而且如果你需要更改它的代碼，就只需要改動一處位置就可以了，用不著把修改好錯誤的版本復(fù)制粘貼到各個地方。
但請注意，D.R.Y. 原則會讓你引入復(fù)雜性。因為到最后，事物被重用的次數(shù)會越來越多。
當(dāng)你開始更改被多次重用的代碼時，針對這部分代碼編寫測試的重要性就會充分體現(xiàn)出來了。
可重用性、可讀性和可維護性彼此之間既是朋友也是敵人。當(dāng)你開始在自己的代碼中踐行 D.R.Y. 原則，你就會引入復(fù)雜性。當(dāng)你引入復(fù)雜性時，可讀性水平可能就會下降了。
因此，在構(gòu)建功能時不要想著先做一個通行的解決方案。從簡單入手是最好的！第一次嘗試肯定沒法做到盡善盡美。
通過多次迭代，你就可以在重用應(yīng)用程序很多部分的同時，仍然保持不錯的可讀性和可維護性。
當(dāng)你在擁有許多開發(fā)團隊的組織中工作時，你的團隊可能會分為內(nèi)部人員和外部人員（例如自由職業(yè)者或顧問）。因此在這種情況下，人們會經(jīng)常在不同組織之間來回切換。
在這些場景中，可讀性和可維護性是成功的關(guān)鍵。讓那些很可能隨時離開團隊的人員來制定通行的解決方案，并不是一個明智的選擇。
在某些情況下，你的確需要通行方案，但這些方案必須做到很容易閱讀和維護。
在為一款應(yīng)用程序構(gòu)建一些新功能時，你可能會在構(gòu)建前作詳細(xì)的規(guī)劃。
最佳的解決方案肯定是能拆分成許多較小的模塊、類或組件的。你想知道為什么嗎？
因為小段代碼更容易測試和維護。
想象一下，人們在現(xiàn)實中搭建高層建筑時，也是從一個個較小的單元開始拼裝而成的，而不是一下子就把整幢大樓都造好，然后設(shè)法安裝到地基上。當(dāng)然了，例外也是有的。
大多數(shù)現(xiàn)代庫和框架都分成了一些較小的構(gòu)造塊，而不是打包成單個文件。像 Angular、React 和 Vue 這樣的 JavaScript 庫和框架都采用了組件的概念。我認(rèn)為他們的選擇并不是無意識的結(jié)果。
想要編寫出可讀和可維護的代碼，一方面要關(guān)注的是代碼的架構(gòu)，另一方面則要關(guān)注代碼的樣式。
我想很多讀者都經(jīng)常會見到關(guān)于制表符或空格縮進(jìn)的討論。不過這里我不會討論這個話題。無論你在團隊中使用的是哪種方案，請確保所有團隊成員都遵守它就行了。
最好的解決方案是，盡可能讓這些代碼樣式規(guī)則和準(zhǔn)則自動化。許多 IDE 都集成了這種功能，或者可以通過插件安裝。
最簡單的一種，也是支持多種語言和代碼編輯器的方案是 editorconfig。只要添加一個.editorconfig，就可以應(yīng)用這些規(guī)則。
https://editorconfig.org/
你可以在這些文件中為你的項目調(diào)整許多設(shè)置。你也可以指定全局設(shè)置方案，或者為特定的語言指定設(shè)置。例如：
縮進(jìn)樣式：制表符或空格
引號類型：單引號或雙引號
最大長度
字符集
還有更多……
# 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ò)上還有許多適用于某些特定語言的工具。對于 JavaScript 來說，我喜歡使用 Prettier，但你可能希望換一些不一樣的工具。
https://medium.com/better-programming/eslint-vs-prettier-57882d0fec1d
不管怎樣，只要參與項目的所有人都遵循相同的規(guī)則和準(zhǔn)則，那么具體使用哪一種方案并不重要。
最后一點也是非常重要的，那就是永遠(yuǎn)都像在團隊中一樣編寫便于協(xié)作的代碼！
我可以想象，從未在團隊中編寫過代碼的開發(fā)人員是很難理解這一條原則的。
可是如果你在一個人編寫項目，就會很容易寫出來很多只有你自己才能理解的代碼（例如編寫模糊不清的變量名、使用 2-3 個字符的變量名等等）。
應(yīng)該試著像在團隊中一樣編寫能方便他人理解的代碼。想象一下，這就是說你的代碼應(yīng)該足夠清晰明了，讓其他人可以輕松理解。
你可以問一問朋友，或者在開發(fā)者社區(qū)中通過 Twitter 找什么人過來幫你檢查代碼的可讀性，這是很簡單的測試方法。我可以保證，你會得到自己意想不到的反饋。
不要擔(dān)心負(fù)面反饋！你只要關(guān)注那些可以讓你的代碼對其他人更具可讀性的反饋意見就行了。
你應(yīng)該知道，可讀代碼與讀起來略吃力的代碼之間并沒有很清晰的界限，不同人會在這個問題上有不同的看法。如果有人告訴你你的代碼很難讀，那也不要難過！你應(yīng)該感謝對方的反饋意見。
- EOF -