linux 機器格式化

by Artem Sapegin

通過Artem Sapegin

為什么機器人應該為我們格式化代碼 (Why robots should format our code for us)

I used to think that a personal code style is a good thing for a programmer. It shows you are a mature developer who knows what good code should look like.

我曾經認為個人代碼樣式對程序員來說是一件好事。 它表明您是一個成熟的開發人員，他知道好的代碼應該是什么樣。

My college professors told me that they knew when some of my classmates used my code in their work because of the different code style. Now I think it was because my code was at least somehow formatted and everyone else’s was a mess.

我的大學教授告訴我，由于某些代碼風格不同，他們知道我的一些同學何時在工作中使用我的代碼。 現在，我認為這是因為我的代碼至少已以某種方式進行了格式化，而其他所有人都陷入了混亂。

Since then I’ve spent a lot of time arguing code style and configuring tools to enforce it. It’s time for a change.

從那時起，我花了很多時間爭論代碼風格并配置工具來實施它。 現在該進行更改了。

一些例子 (A few examples)

After reading the The Programmers’ Stone I put braces like this for a long time:

看完《程序員的石頭》之后，我放了很長時間這樣的括號：

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

But then I realized that I may be the only one who did it that way in the front-end community. Everybody else uses this style:

但是后來我意識到，我可能是前端社區中唯一這樣做的人。 其他人都使用這種風格：

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

Or this:

或這個：

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

So I’ve changed my style to the last one.

因此，我已將樣式更改為上一個樣式。

I like this style for chaining very much:

我非常喜歡這種鏈接樣式：

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

I see the same refactoring benefits as for trailing commas:

我看到了與尾隨逗號相同的重構優勢：

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

But I’m probably even more lonely with this style than I was with braces. Nobody would ever send me code for review with this style, no linter can enforce it. So I have to stop using it too to be closer to the real world.

但是我可能比使用牙套更孤單。 沒有人會以這種樣式向我發送代碼以供審查，沒有短毛絨犬可以強制執行它。 因此，我也必須停止使用它以更接近真實世界。

There’s another thing that nobody else does except me . I always put two spaces before end-of-the-line comment:

除了我以外，沒有人能做的另一件事。 我總是在行尾注釋前放置兩個空格：

const volume = 200;  // ml

I thought it improves readability. But it actually makes the codebase inconsistent because other developers only put one space.

我認為它可以提高可讀性。 但這實際上使代碼庫不一致，因為其他開發人員只放置了一個空格。

JavaScript開發人員的工作 (What JavaScript developers do)

Unfortunately JavaScript has no official code style. There are a few popular code styles like Airbnb or Standard. You could use them to make your code look familiar to other developers.

不幸的是，JavaScript沒有官方代碼風格。 有一些流行的代碼樣式，例如Airbnb或Standard 。 您可以使用它們使您的代碼看起來對其他開發人員熟悉。

You could use ESLint to enforce code style and even autoformat code in some cases. But it won’t make your code base 100% consistent. ESLint with Airbnb config would normalize only my first example and allow inconsistency in the other two examples.

在某些情況下，您可以使用ESLint強制執行代碼樣式，甚至自動格式化代碼。 但這不會使您的代碼庫100％一致。 帶有Airbnb配置的ESLint僅會規范我的第一個示例，而在其他兩個示例中允許不一致。

JavaScript開發人員應該做什么 (What JavaScript developers should do)

Some languages have strict code styles and tools to format code. So developers don’t waste time arguing code style. Look at Refmt for Reason and Rustfmt for Rust.

一些語言具有嚴格的代碼樣式和格式化代碼的工具。 因此，開發人員不會浪費時間爭論代碼風格。 在Refmt中查找原因，在Rustfmt中查找Rust。

It looks like JavaScript finally has a solution to this problem. A new tool called Prettier will reformat your code using its own rules. It completely ignores how the code was written in the first place.

看來JavaScript終于可以解決此問題。 一個名為Prettier的新工具將使用其自己的規則重新格式化您的代碼。 首先，它完全忽略了代碼是如何編寫的。

Let’s try Prettier on my examples:

讓我們在示例中嘗試更漂亮 ：

if (food === 'pizza') {  alert('Pizza ;-)');} else {  alert('Not pizza ;-(');}function foo(items) {  return items.filter(item => item.checked).map(item => item.value);}const volume = 200; // ml

You can disagree with this style. For example I don’t like the else placement and writing function chains in one line is questionable. But I see huge benefits in adopting Prettier:

您可以不同意這種風格。 例如，我不喜歡else放置和在一行中編寫函數鏈是有問題的。 但是我發現采用Prettier具有巨大的好處：

• Almost no decisions to make — Prettier has few options.
  幾乎沒有任何決定-Prettier幾乎沒有選擇。
• No arguing about particular rules if you’re working in a team.
  如果您在團隊中工作，則無需爭論特定的規則。
• No need to learn your project’s code style for contributors.
  無需為貢獻者學習項目的代碼風格。
• No need to fix style issues reported by ESLint.
  無需修復ESLint報告的樣式問題。
• Possible to set up autoformat on file save.
  可以在文件保存時設置自動格式化。

結論 (Conclusion)

Prettier has been already adopted by some popular projects like React and Babel. And I’m starting to convert all my projects from my custom code style to Prettier. I will recommend it instead of the Airbnb code style.

Prettier已被React和Babel等一些受歡迎的項目采用。 我開始將所有項目從我的自定義代碼樣式轉換為Prettier。 我會推薦它而不是Airbnb代碼樣式。

At first I had a lot of “Ugh, that’s ugly” moments with Prettier. But when I think that I’d have to, for example, manually reformat JSX code from a single-line to multi-line when I add another prop and it doesn’t fit on one line — I realize that it’s totally worth it.

起初，我和Prettier在一起經歷了很多“丑陋，丑陋”的時刻。 但是，當我認為我必須(例如)在添加另一項道具時將JSX代碼從單行手動重新格式化為多行時，又不適合一行，我意識到這是完全值得的。

Read how to set up Prettier in your project.

閱讀如何在項目中設置Prettier 。

P. S. Have a look at my new tool that will simplify adding ESLint, Prettier, and other tools to your project, as well as keeping their configs in sync.

PS 看看我的新工具 ，它將簡化向您的項目中添加ESLint，Prettier和其他工具的過程，并使它們的配置保持同步。

Subscribe to my newsletter: https://tinyletter.com/sapegin

訂閱我的新聞通訊： https : //tinyletter.com/sapegin

翻譯自: https://www.freecodecamp.org/news/why-robots-should-format-our-code-159fd06d17f7/

linux 機器格式化