我爲何推薦Prettier來統一代碼風格

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

• 原文: Why robots should format our code for us
• 譯者: Fundebug

爲了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原做者全部，翻譯僅用於學習。

我曾經覺得，程序員有本身獨特的代碼風格挺好的。由於，一個成熟的程序員應該清楚，好的代碼應該是怎樣的。

個人大學教授告訴我，他的學生在用個人代碼，由於個人代碼風格不同。我想了一下，也許是由於個人代碼至少是有風格的，而其餘人的代碼一團糟。

一些示例

示例 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/