我為什麼推薦Prettier來統一程式碼風格

Fundebug發表於2019-03-21

譯者按: 關於程式碼風格，不同的人有不同的偏好，其實並沒有什麼絕對的對錯。但是，有 2 條原則應該是對的： 少數服從多數；用工具統一風格。

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原作者所有，翻譯僅用於學習。

我曾經以為，程式設計師有自己獨特的程式碼風格挺好的。因為，一個成熟的程式設計師應該清楚，好的程式碼應該是怎樣的。

我的大學教授告訴我，他的學生在用我的程式碼，因為我的程式碼風格不一樣。我想了一下，也許是因為我的程式碼至少是有風格的，而其他人的程式碼一團糟。

一些示例

示例 1：

讀了The Programmers’ Stone之後，我把大括號這樣寫：

if (food === 'pizza')
{
    alert('Pizza ;-)');  
}
else
{  
    alert('Not pizza ;-(');
}

但是，我意識到在前端社群裡，也許只有我一個人這樣寫的。而其他人都是這樣寫的：

if (food === 'pizza') {
    alert('Pizza ;-)');  
} else {
    alert('Not pizza ;-(');
}

或者這樣：

if (food === 'pizza') {
    alert('Pizza ;-)');  
}
else {  
    alert('Not pizza ;-(');
}

於是，我改變了風格，採用了最後一種寫法。

示例 2

將多個方法連結起來時，我喜歡這樣寫：

function foo(items) {
  return items
    .filter(item => item.checked)
    .map(item => item.value)
  ;
}

示例 3

讀了Why you should enforce Dangling Commas for Multiline Statements，我意識到了trailing commas寫法更加易於重構：

const food = [
  'pizza',
  'burger',
  'pasta',
]

但是，這種寫法非常少見。我審查過的程式碼中，沒人這樣寫。於是，我只能放棄這種寫法，向現實世界低頭。

示例 4

我還有一個不合群的習慣。在行尾寫程式碼註釋之前，我習慣敲 2 個空格：

const volume = 200;  // ml

我覺得這樣寫好看些。但是，這會導致程式碼不一致，因為其他人只敲一個空格。

JavaScript 開發者是怎樣做的

很遺憾，JavaScript 沒有官方的程式碼風格。業界有一些流行的程式碼風格，比如Airbnb和Standard。使用它們的話，團隊成員之間的程式碼會更易讀。

你也可以使用ESLint 來統一風格。但是它並不能保證程式碼 100%一致。比如，ESLint 的 Airbnb 配置，只能統一示例 1的程式碼風格，而不能統一後面兩者。

JavaScript 開發者應該怎麼做？

有一些語言有非常嚴格的程式碼風格，並且有工具可以用於統一風格。因此，開發者不需要浪費時間去爭論程式碼風格的優劣。例如，Reason 語言的Refmt，和 Rust 語言的Rustfmt。

現在，JavaScript 終於有了一個解決方案。有一個新工具，叫做Prettier，它運用自身的規則將你的的程式碼重新格式化。無論你之前的程式碼風格是怎樣。

我們不妨試用一下 Prettier。

輸入程式碼是這樣的：

if (food === 'pizza')
{
    alert('Pizza ;-)');  
}
else
{  
    alert('Not pizza ;-(');
}

function foo(items) {
  return items
    .filter(item => item.checked)
    .map(item => item.value)
  ;
}

const food = [
  'pizza',
  'burger',
  'pasta',
]

Prettier 處理之後的程式碼是這樣的：

if (food === "pizza") {
    alert("Pizza ;-)");
} else {
    alert("Not pizza ;-(");
}

function foo(items) {
    return items.filter(item => item.checked).map(item => item.value);
}

const food = ["pizza", "burger", "pasta"];

也許，你並不喜歡這種風格。比如，我不喜歡 else 放在大括號後面，也不喜歡把鏈式方法全部寫在同一行。但是，我發現使用Prettier有很多益處：

  • 幾乎不需要做決定，因為  Prettier 的配置選項很少。
  • 團隊成員不需要為規則去爭論。
  • 開原始碼開發者不需要去學習專案的程式碼風格。
  • 不需要去修復 ESLint 報告的風格問題。
  • 儲存檔案的時候可以自動統一風格。

結論

Prettier 已經被一些非常流行的專案比如 React 和 Babel 採用了。對於我自己的專案，我已經開始從自己的個性化風格全部轉為 Prettier 風格。相比於 Airbnb 程式碼風格，我更推薦 Prettier。

剛開始，我會覺得 Prettier 風格非常差。但是，當我發現自己需要手動去調整程式碼風格時，我意識到 Prettier 真的非常好用。

Prettier 可以在儲存檔案的時候可以自動統一風格：

感興趣的話，可以按照這個教程配置 Prettier。

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟體、百姓網等眾多品牌企業。歡迎大家免費試用！

版權宣告

轉載時請註明作者Fundebug以及本文地址：
https://blog.fundebug.com/2017/10/23/format-code-use-Prettier/

相關文章