[[356604]]

可讀的代碼是可維護的

在這篇短文中，我將介紹一些你可以用來改進你的代碼的方法。本文代碼示例均使用 JavaScript。

我發(fā)現(xiàn)但凡是可讀的代碼必定是可維護的。

作為一名開發(fā)人員，我的目標是編寫高質(zhì)量的代碼。團隊中的每個開發(fā)人員，不管他/她的技術(shù)水平如何，都必須能夠通過閱讀理解我所寫的代碼。代碼的可讀性有助于年輕的開發(fā)人員編寫代碼時更加自信。

刪除 不必要的 代碼注釋

當然，有些代碼可以非常復雜。我深知這一點且見過很多次。在復雜的代碼中，我會寫些適當?shù)奈臋n和代碼注釋。

別誤會。我不是代碼注釋或 JavaScript JSdoc 的愛好者，而且基本上我能不用它們便不用。

我不需要任何注釋來解釋這個接收 X 個數(shù)組并將它們合并到一個新的數(shù)組中的函數(shù)。

function mergeArrays(...arrays) { 
  let mergedArray = [] 
 
  arrays.forEach(array => { 
      mergedArray = [...mergedArray, ...array] 
  }) 
 
  return mergedArray 
} 

像示例代碼，如果增添文檔并不能提高可讀性。我希望團隊成員知道展開操作符是什么。如果他們不清楚，他們應該在代碼審查 code review 時來問我。

當然，我們不要忘記注釋的代碼塊。如果我們忘記了，這里只有一個解決方案： 刪除代碼 。既然了不起的 git 可以檢出舊代碼，那么為什么還要把它留在注釋中呢？

請停止把你的代碼庫變成垃圾場。

重視命名

如果你看到函數(shù)名 mergeArrays，就應該很清楚地知道這是一個將 X 個數(shù)組組合成一個新的數(shù)組的函數(shù)。

我知道命名是件難事。函數(shù)越復雜，命名就越難… 我有個法子讓命名更容易，舉個例子：有一個函數(shù)，它會合并兩個數(shù)組并生成一個新的唯一的數(shù)字列表。你會怎么命名？是下面這樣嗎？

function mergeNumberListIntoUniqueList(listOne, listTwo) { 
  return [...new Set([...listOne, ...listTwo])] 
} 

mergeNumberListIntoUniqueList 這個名字并沒有那么糟糕，至少功能如其名。命名的難點在于這個函數(shù)要做兩件事：一個函數(shù)做的事情越多，命名它就越困難。將這個函數(shù)拆分為兩個單獨的函數(shù)，命名會更容易且函數(shù)復用更容易。

function mergeLists(listOne, listTwo) { 
  return [...listOne, ...listTwo] 
} 
 
function createUniqueList(list) { 
  return [...new Set(list)] 
} 

當然，不需要調(diào)用新函數(shù)就可以很容易地創(chuàng)建美觀的一行代碼。但有時，一行代碼的可讀性并不高。

If 語句

我對這個問題的命名無力… 看！命名不易…

但我經(jīng)常看到這種情況。

問題

if(value === 'duck' || value === 'dog' || value === 'cat') { 
  // ... 
} 

解決方法

const options = ['duck', 'dog', 'cat']; 
if (options.includes(value)) { 
  // ... 
} 

這樣做，你創(chuàng)建了一段像是英語句子般的可讀代碼。

如果選項包含值，那么 ...

提前退出機制

這個準則有很多種命名方式，但我選擇了 “提前退出 Early exit” 這個名字。

讓我給你們看一段代碼。我相信你們以前見過這樣的東西。

function handleEvent(event) { 
  if (event) { 
    const target = event.target; 
    if (target) { 
      // Your awesome piece of code that uses target 
    } 
  } 
} 

來我們檢查下對象 event 是否為真，以及屬性 target 是否可用。問題是上面代碼我們已經(jīng)用了兩個 if 語句。

讓我們看看如何在這里實現(xiàn) “提前退出”。

function handleEvent(event) { 
  if (!event || !event.target) { 
    return; 
  } 
  // Your awesome piece of code that uses target 
} 

在這里用 “提前退出”，你可以檢查是否 event 和   event.target 同時非假 。很明顯，我們確信這一事件 event.target 非假。因為如果這個語句為假，程序就不會執(zhí)行其他代碼。

解構(gòu)賦值

在 JavaScript 中，我們可以解構(gòu)數(shù)據(jù)和對象。

根據(jù) developer.mozilla.org 上的文檔， 解構(gòu)賦值語法是一種 JavaScript 表達式。通過解構(gòu)賦值，可以將值從數(shù)組、屬性從對象中取出，賦值給其他變量 。

一些代碼示例

// Destructuring an object 
const numbers = {one: 1, two: 2}; 
const {one, two} = numbers; 
console.log(one); // 1 
console.log(two); // 2 
 
// Destructuring an array 
const numbers = [1, 2, 3, 4, 5]; 
const [one, two] = numbers; 
console.log(one); // 1 
console.log(two); // 2 

解構(gòu)的問題在于，它有時會為屬性創(chuàng)建一個不好的命名。最好的例子是從 API 獲取數(shù)據(jù)并接收具有 data 屬性的響應對象。

const url = "http://localhost:8080/api/v1/organizers/1" 
const response = await axios.get(url) 
const {name} = response.data 

這個代碼示例說明你正在獲取 id 為 1 的 organizer。organizer 對象有一個名字，你可以解構(gòu)它。這樣做沒什么問題。

這段代碼可以正常運行。但是為什么屬性名還是 name ? 那將是整個范圍中唯一的 name 屬性嗎？屬性名又來自哪個對象？

通過重命名屬性可避免這些問題。

const url = "http://localhost:8080/api/v1/organizers/1" 
const response = await axios.get(url) 
const {name: organizerName} = response.data 

這段代碼變得更具可讀性。每個人都知道變量是 organizer 的名字。

童子軍規(guī)則

聽過這樣一句話嗎：“永遠保持離開時的露營地比你發(fā)現(xiàn)它時更整潔”？

這就是童子軍的規(guī)則。讓代碼比發(fā)現(xiàn)時更好。你發(fā)現(xiàn)代碼異味 code smell？重構(gòu)它！你發(fā)現(xiàn)一個未使用的變量？刪除它！

我喜歡把童子軍規(guī)則和打掃房間的情況進行類比。想象一下，你家里的每個人都把盤子放在水槽上，把所有垃圾都放在走廊上，把所有要洗的衣服都放在浴室里。但是每個星期天，你必須花費 4 個多小時清理整個房子。你會鐘意嗎？

我肯定答案是 NO。所以如果每個人都立即清理房間的小部分，星期天的工作量會小一些。

代碼庫同理。如果每個小的代碼異味 code smell 都留在代碼庫中，沒有人刪除未使用的變量，linter 就會抓狂且有大約 77 個 warning。而且代碼庫將會有很多清潔工作要做，但是如果每個人都承擔起自己的責任并遵守童子軍法則，很多問題將會得到解決。

代碼風格

同樣重要的還有確定團隊中的代碼風格。

我不 care 你是喜歡單引號還是雙引號，空格還是 tab，結(jié)尾逗號還是不用。選擇一種風格并堅持下去。你可以用 Linter 或者 Prettier 來做這件事。

有很多工具可以用來解決代碼風格問題。我最鐘意的是使用 Husky 預提交鉤子。Prettier 的文檔中也有一個關(guān)于預提交鉤子的頁面。

這個預提交鉤子總是在每次提交之前運行配置好的命令。如果你正確地配置它，它會運行得更漂亮，并對所有文件應用所有規(guī)則。這確保了團隊總是擁有統(tǒng)一的代碼風格，而沒有任何糟糕的代碼。

小結(jié)

我知道有些方法顯而易見，有些則不是。但作為一名全職開發(fā)人員，我在不同的代碼庫上工作。這些規(guī)則的重要性只有在較大的代碼庫中才會突顯。但這并不意味著你不應該將這些方法用在小項目中，提高你的代碼質(zhì)量讓小項目更高效。它讓團隊成員方便地閱讀你的代碼并合并你的 pull 請求。正如我所說的，可讀的代碼更容易維護，當然可讀的代碼還有其他更多的好處。

如果你想了解更多關(guān)于代碼整潔之道的知識，可以嘗試閱讀羅伯特・馬丁的《代碼整潔之道》。

原文地址：Clean up your code by applying these 7 rules :zap:️

原文作者：Joachim Zeelmaekers（已授權(quán)）

譯者 & 校正：HelloGitHub-小魚干 & HelloGitHub-鴨鴨