linux 机器格式化_为什么机器人应该为我们格式化代码

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