我為什么推薦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以及本文地址：
https://blog.fundebug.com/2017/10/23/format-code-use-Prettier/