功能箭头_我不讨厌箭头功能

功能箭头

TL; DR (TL;DR)

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

箭头函数适合某些用法，但是它们有很多变化，需要仔细控制它们，以免破坏代码的可读性。

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there's a wide variety of opinions on what makes "good" usage of => and not.

尽管箭头功能显然已经在社区中得到了普遍的共识(尽管不是一致支持！)，但事实证明，对于=> “良好”用法和不正确的用法，存在着各种各样的意见。

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

可配置的lint规则是解决箭头功能的多样性和分歧的最佳解决方案。

I released proper-arrows ESLint plugin with several configurable rules to control => arrow functions in your code base.

我发布了带有几个可配置规则的专有箭头 ESLint插件 ，用于控制代码库中的=>箭头功能。

意见就像鼻子... (Opinions are like noses...)

Anyone who's followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that's the only thing I'm an expert on -- my own opinions -- and I'm never at a loss for them!

长期关注我(推文，书籍，课程等)的任何人都知道我有很多意见。 实际上，那是我唯一的专家-我的观点-我永远不会为他们感到困惑！

I don't subscribe to the "strong opinions, loosely held" mantra. I don't "loosely hold" my opinions because I don't see any point in having an opinion if there isn't sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

我不赞成“强烈意见，松散持有”的口头禅。 我没有“松散地持有”我的观点，因为如果没有足够的理由，我没有任何意见。 在形成可以公开分享的观点之前，我花费了大量时间进行研究，修改，撰写和尝试想法。 在这一点上，我的观点在必要时已得到强烈支持。

What's more, I teach based on these opinions -- thousands of developers in different companies all over the world -- which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I'm tremendously privleged to be in such a position.

更重要的是，我根据这些意见进行授课-全世界数千家不同公司的开发人员-这使我有机会通过无数次讨论和辩论来深入审查我的意见。 我非常有权担任这样的职位。

That doesn't mean I can't or won't change my opinions. As a matter of fact, one of my most strongly held opinions -- that JS types and coercion are useful in JS -- has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

这并不意味着我无法或不会改变自己的观点。 事实上，我最坚定的观点之一-JS类型和强制性在JS中很有用-近来已经发生了相当大的变化。 我对JS类型以及为什么知道类型的工具很有用的观点更加全面和深入。 甚至我对=>箭头功能(本文的重点)的看法也得到了发展和深化。

But one of the things many people tell me they appreciate about me is, I don't just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

但是，许多人告诉我，他们欣赏我的一件事是，我不仅陈述意见，而且还经过深思熟虑的推理来支持这些意见。 即使人们强烈反对我的观点，他们也常常称赞我至少拥有这些观点并给予支持。

And I try to inspire the same in others through my speaking, teaching, and writing. I don't care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that's a healthy relationship with technology.

而且我会通过我的演讲，教学和写作来激发他人的灵感。 我不在乎您是否同意我的意见，我只是在乎您知道您为什么拥有技术意见，并可以用自己的推理来认真辩护。 对我来说，这是与技术之间的健康关系。

箭头函数！= function s (Arrow Functions != functions)

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don't find them more readable in most cases. And I'm not alone. Any time I share an opinion like that on social media, I often get dozens of "me too!" responses peppered in with the scores of "you're totally wrong!" responses.

我坚信=>箭头函数不适合用作JS代码中所有(甚至大多数) function通用替代品。 在大多数情况下，我确实不觉得它们更具可读性。 我并不孤单。 每当我在社交媒体上发表这样的观点时 ，我常常会得到数十个 “我也是！”。 React与充塞分数的“你完全错了！ ”回应。

But I'm not here to rehash the entire debate over => arrow functions. I've written extensively about my opinions on them, including these sections in my books:

但是我不是在这里重新讨论整个=>箭头函数的争论。 我已经就它们的观点写了很多篇文章，包括我书中的以下部分：

• "You Don't Know JS: ES6 & Beyond", Ch2, "Arrow Functions"

  “您不了解JS：ES6及更高版本”，第2章，“箭头功能”

• "Functional-Light JavaScript", Ch2, "Functions Without function" (and the preceding section on function names).

  “功能轻型JavaScript”，第2章，“无function ” (以及前面有关函数名称的部分)。

Whatever your preferences around =>, to suggest that it's only a better function is to be plainly reductive. It's a far more nuanced topic than just a one-to-one correspondence.

无论您对=>的偏好是什么，表明它只是一个更好的 function ，都是简单地归纳一下。 这不仅仅是一对一的对应，更是一个微妙的话题。

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

关于=>有些事情值得喜欢。 你可能会发现，令人惊讶的对我说，因为大多数人似乎认为我讨厌箭头功能。

I don't (hate them). I think there are definitely some important benefits.

我不(恨他们)。 我认为肯定有一些重要的好处。

It's just that I don't unreservedly endorse them as the new function. And these days, most people aren't interested in nuanced opinions in the middle. So since I'm not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

只是我不会毫无保留地认可它们为新function 。 如今，大多数人对中间的细微差别不感兴趣。 所以，因为我不是完全亲=>营，我必须完全在反对派阵营。 不对 。

What I hate is suggesting they're universally more readable, or that they're objectively better in basically all cases.

我讨厌的是暗示它们普遍更具可读性，或者在基本上所有情况下它们在客观上都更好 。

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. "There must be something wrong with me, since I don't think it's more readable. Why do I suck so much at this?" And I'm not the only one whose impostor syndrome is seriously stoked by such absolutes.

我拒绝这一立场的原因是，在许多情况下， 我确实努力阅读它们 。 因此，这种观点让我作为开发人员感到愚蠢/自卑。 “我一定有什么问题，因为我不认为这更易读。为什么我对此太烂了？” 而且，我并不是唯一一个被这样的绝对观点严重推崇冒名顶替者的人。

And the cherry on top is when people tell you that the only reason you don't understand or like => is because you haven't learned them or used them enough. Oh, right, thanks for the (condescending) reminder it's due to my ignorance and inexperience. SMH. I've written and read literally thousands of =>functions. I'm quite certain I know enough about them to hold the opinions I have.

最让人讨厌的是，当人们告诉您，您不了解或不喜欢=>的唯一原因是因为您没有学习或充分使用它们。 哦，对了，谢谢(递减)提醒，这是由于我的无知和经验不足。 SMH。 我已经编写并阅读了成千上万的=>函数。 我很确定我对他们足够了解，可以发表自己的看法。

I'm not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

我不在赞成=>阵营中，但我认识到有些人确实确实确实喜欢它们。 我认识到有些人来自使用=>语言的JS，因此他们的感觉和阅读非常自然。 我认识到，有些人更喜欢它们类似于数学符号。

What's problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

IMO的问题在于，那些营地中的一些人根本无法理解或同情反对意见，好像他们的观点一定有问题 。

可读性！=可写性 (Readability != Writability)

I also don't think you know what you're talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

当您谈论代码可读性时，我也不认为您在说什么。 总的来说，当您分解代码时，关于代码可读性的绝大多数意见都是基于个人对编写简洁代码的偏好的立场。

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, "readability is all just subjective anyway".

当我回退有关代码可读性的辩论时，有些人只是跟在他们后面，拒绝支持他们的观点。 其他人则可以免除这些担忧，“可读性无论如何都是主观的”。

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, "well, I think it's more readable, even if ignorants like you don't."

这种React的脆弱感令人震惊：两秒钟前，他们强烈宣称=>箭头绝对客观地更具可读性，然后按下时，他们承认：“好吧， 我认为它更具可读性，即使像你这样的无知者也不会”。

Guess what? Readability is subjective, but not entirely so. It's a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

你猜怎么了？ 可读性是主观的， 但不完全 是主观的。 这是一个非常复杂的话题。 并且有些人正致力于正式研究代码可读性主题，试图找出其中的哪些部分是客观的，哪些部分是主观的。

I have read a fair amount of such research, and I'm convinced that it's a complicated enough topic that it can't be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

我已经阅读了大量此类研究，并且我坚信这是一个非常复杂的主题，不能将其简化为T恤衫上的标语。 如果您想阅读它们，我鼓励您自己做一些Google搜索和阅读。

While I don't have all the answers myself, one thing I'm certain about is, code is more often read than written, so perspectives on the topic which ultimately come from "it's easier/quicker to write" don't hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

尽管我自己并没有所有答案，但我可以肯定的一件事是，代码的阅读和编写往往比编写的要多，因此，对该主题的看法最终源于“编写起来更容易/更快捷”，但观点并不多常设。 需要考虑的是，不是您节省了多少时间，而是读者(将来对您或团队中的其他人)有多清晰的理解能力？ 理想情况下，他们能否在不花哨的梳子倾倒代码的情况下大体上理解它？

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

任何试图以可证明的可读性好处的说法来证明可写性能力的理由充其量只是一个微弱的论点，总的来说，只是分散注意力。

So I roundly reject that => is always and objectively "more readable".

因此，我完全拒绝=>始终客观地“更具可读性”。

But I still don't hate arrow functions. I just think to use them effectively, we need to be more disciplined.

但是我仍然不讨厌箭头功能。 我只是想有效地使用它们，我们需要更加纪律。

短毛==纪律 (Linters == Discipline)

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that's not their primary purpose.

您可能以(错误的)信念认为，lint会告诉您有关代码的客观事实。 他们可以做到这一点，但这不是他们的主要目的。

The tool that's best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that's best suited to tell you whether your code is "correct" (does what you want it to do) is your test suite.

最能告诉您代码是否有效的工具是编译器(即JS引擎)。 测试套件是最适合告诉您代码是否“正确”(做您想要做的事情)的工具。

But the tool that's best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems -- according to the authors of those opinion-based rules.

但是最适合告诉您代码是否合适的工具是linter。 根据这些基于意见的规则的作者所说，Linters是关于如何应样式和结构化代码的自以为是的规则集合，从而避免可能出现的问题。

That's what they're for: to apply opinions to your code.

那就是他们的目的： 将意见应用于您的代码。

That means it's almost certain that these opinions will, at one time or another, "offend" you. If you're like most of us, you fancy yourself pretty good at what you do, and you know that this thing you're doing on this line of code is right. And then the linter pops up and says, "Nope, don't do it that way."

这意味着几乎可以肯定，这些意见会一次或一次“冒犯”您。 如果您像我们大多数人一样，那么会幻想自己做的事很不错，并且您知道在此代码行中所做的这件事是正确的 。 然后短绒弹出，然后说：“不，不要那样做。”

If your first instinct is sometimes to disagree, then you're like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we're wrong, we chuff a little bit.

如果您的第一本能有时会不同意，那么您就像我们其他人一样！ 我们在情感上依附于自己的观点和能力，当一种工具告诉我们我们错了时，我们就会有些挣扎。

I don't get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter's opinion disagrees with mine.

我不会对测试套件或JS引擎感到生气。 这些都是关于我的代码的事实报告。 但是当小子的意见与我的意见不同时，我一定会很生气。

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90's sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

我有几周前启用的一条linter规则，因为我的编码不一致，在重新读取代码时很烦人。 但是现在，这条不起毛的规则每小时出现两次或三次，像90年代情景喜剧中的刻板奶奶一样me我。 每一次，我都会思考(只是一会儿)是否应该禁用该规则。 我把它留着，但令我很恼火。

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

那么为什么要遭受这种折磨呢？ 因为短绒棉签的工具和他们的见解使我们纪律严明。 他们帮助我们与他人合作。

They ultimately help us communicate more clearly in code.

它们最终帮助我们在代码中进行更清晰的沟通。

Why shouldn't we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we're in the trenches working on our own code, against unreasonable pressure and deadlines, we're in the least trustable mindset to be making those judgement calls.

我们为什么不让每个开发人员都做出自己的决定？ 因为我们倾向于情感依恋。 当我们在努力制定自己的代码时 ，面对不合理的压力和期限，我们以最不值得信赖的心态进行这些判断。

We should be submitting to tools to help us maintain our discipline.

我们应该致力于帮助我们保持纪律的工具。

It's similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we're level headed enough to make that analysis. We don't institute that kind of process when our code is hopelessly broken and we have no idea why and we're just resorting to trying random code changes to see if they fix it!

这类似于TDD倡导者通过一套正式步骤首先屈从于编写测试学科的方式。 当我们有足够的头脑去进行分析时，我们最看重的是流程的纪律性和全局效果。 当我们的代码被无可避免地破坏时，我们不会建立这样的过程，我们也不知道为什么，我们只是尝试尝试对随机代码进行更改以查看它们是否得以解决！

No. If we're being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

不。如果我们很理性，我们承认当我们制定合理的准则并遵循遵守准则的原则时， 整体利益才是最好的。

可配置性为王 (Configurability Is King)

If you're going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you're required to play by. Arbitrary and unassailable opinions are the worst kind.

如果您要故意使自己遭受手指摇动，那么您(和您的团队，如果适用)肯定会想要说一句话，因此您需要遵循什么规则。 武断而无懈可击的意见是最糟糕的一种。

Remember the JSLint days when 98% of the rules were just Crockford's opinions, and you either used the tool or you didn't? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

还记得JSLint时代，当时98％的规则只是Crockford的意见，而您使用了该工具还是没有使用？ 他直接在自述文件中警告您，您将被冒犯，您应该克服它。 很好玩吧？ (有些人可能仍在使用JSLint，但我认为您应该考虑使用更现代的工具！)

That's why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

这就是为什么ESLint如今是短绒棉之王 。 从根本上讲，这种哲学是让一切都是可配置的。 让开发人员和团队出于自己的纪律和利益，民主决定他们都想提交哪些意见。

That doesn't mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a "centralized standard", that has the best chance of communicating most clearly to the most developers on the team.

这并不意味着每个开发人员都会选择自己的规则。 规则的目的是使代码符合合理的折衷方案，即“集中式标准”，这是与团队中大多数开发人员进行最清晰沟通的最佳机会。

But no rule is ever 100% perfect. There's always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

但是，没有规则是100％完美的。 总是有例外情况。 例如，这就是为什么可以选择禁用或重新配置带有嵌入式注释的规则的原因，它不仅是一个很小的细节，而且是一项关键功能。

You don't want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

您不希望开发人员仅拥有自己的本地ESLint配置，该配置在提交代码时会覆盖规则。 对于开发人员而言，您想要的是遵循既定规则(首选！)， 或者在发生异常时对明确且显而易见的规则进行例外处理。

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn't. But at least it was obvious, and at least it was possible to be discussed in the first place.

理想情况下，在代码审查期间，可以讨论，辩论和审查该异常。 也许是有道理的，也许不是。 但是至少这是显而易见的，至少可以首先进行讨论。

Configurability of tools is how we make tools work for us instead of us working for the tools.

工具的可配置性是我们使工具为我们工作而不是为工具工作的方式。

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there's no discussion or debate. I'm know that works for some developers and for some teams, but I don't think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

一些人更喜欢基于约定的工具方法，因为规则是预先确定的，因此没有讨论或辩论。 我知道这种方法适用于某些开发人员和某些团队，但是我认为这不是通用，广泛应用的可持续方法。 最终，一种无法适应不断变化的项目需求和使用它的开发人员的DNA的工具最终将变得晦涩难懂，并最终被替换。

正确的箭 (Proper Arrows)

I fully recognize my usage of the the word "proper" here is going to ruffle some feathers. "Who is getify to say what is proper and not?"

我完全认识到我对“适当”一词的用法会引起一些麻烦。 “谁在说什么是合适的而不是合适的？”

Remember, I'm not trying to tell you what is proper. I'm trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

记住，我并不是要告诉你什么是正确的。 我试图让您接受这样一个想法，即关于=>箭头函数的意见随其语法和用法的所有细微差别而变化，并且最终最合适的是一些意见 ，无论它们是什么，应适用。

While I'm a big fan of ESLint, I've been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I'm frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

虽然我是ESLint的忠实拥护者，但我对内置ESLint规则缺乏对=>箭头函数各个方面的控制的支持感到失望。 这里 有 一个 少数内置的规则，但我很沮丧，他们似乎主要集中在像空白肤浅的风格细节。

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

我认为有很多方面可能会妨碍=>箭头函数的可读性，这些问题远远超出了当前ESLint规则集可以控制的范围。 我在Twitter上 问了一下，从许多答复看来，很多人对此都有意见。

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

终极的lint不仅可以让您根据自己的喜好配置规则，还可以在缺少某些内容时构建自己的规则。 幸运的是，ESLint完全支持这一点！

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

因此，我决定构建一个ESLint插件来围绕=>箭头函数： proper-arrows定义一组附加规则。

Before I explain anything about it, let me just point out: it's a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

在我对它进行任何解释之前，我只想指出：这是一组规则，您可以自行决定打开或关闭并配置它们。 如果您发现某条规则的一个细节都无济于事，那么使用规则/插件总比没有好。

I'm fine with you having your own opinions on what makes => arrow functions proper. In fact, that's the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

对于让=>箭头功能正常运行的问题，您有自己的看法，我很好。 实际上，这就是重点。 如果我们都对=>箭头功能有不同的意见，则应该有工具支持让我们选择和配置这些不同的意见。

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don't want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

此插件的原理是，对于每个规则，当您打开该规则时，默认情况下都会启用其所有报告模式。 但是您当然可以不打开规则，也可以打开规则，然后根据需要配置其模式。 但是我不希望您不得不去寻找打开规则/模式，因为规则/模式的模糊性甚至阻止了它们的考虑。 因此，每条规则都应遵循所有规则。

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

唯一的例外是默认情况下，所有规则都忽略琐碎=>箭头函数 ，例如() => {} ， x => x等。如果要检查这些x => x ，则必须按规则进行检查使用{ "trivial": true }选项打开该检查。

正确的箭法 (Proper Arrows Rules)

So what rules are provided? Here's an excerpt from the project overview:

那么提供了哪些规则？ 这是项目概述的摘录 ：

• "params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

  "params" ：控制=>箭头功能参数的定义，例如禁止未使用的参数，禁止短/不语义的参数名称等。

• "name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

  "name" ：要求=>箭头函数只能在接收到推断名称(即，分配给变量或属性等)的位置使用，以避免匿名函数表达式的易读性/可调试性。

• "where": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

  "where" ：限制其中的程序结构=>箭头功能可被使用：在顶层/全球范围禁止他们，对象属性， export语句等

• "return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

  "return" ：限制简明的返回值类型用于=>箭头函数，例如，禁止对象文字简明返回( x => ({ x }) )，禁止条件/三元表达式的简明返回( x => x ? y : z )等

• "this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

  "this" ：在this =>箭头函数本身或嵌套的=> arrow函数中，需要/不允许=>箭头函数使用this引用。 这个规则可以任选禁止this含=>从全球范围箭头功能。

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

请记住，每个规则都有多种配置模式，因此这都不是全部。 选择适合您的东西。

As an illustration of what the proper-arrows rules can check for, let's look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

为了说明适当的箭头规则可以检查的内容，让我们看一下"return"规则 ，特别是其"sequence"模式 。 此模式将=>箭头函数的简明返回表达式表示为逗号分隔的序列 ，如下所示：

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

序列通常用在=>箭头函数中，以简洁的形式将多个(表达式)语句返回到字符串中，而无需使用完整的{ .. }分隔的函数体和显式的return语句。

Some may love this style -- that's OK! -- but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

有些人可能喜欢这种风格-没关系！ -但是很多人认为它更喜欢简洁的样式编码，而不是可读性，他们更喜欢：

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it's still an => arrow function and it's not even that many more characters. But it's clearer that there are three separate statements in this function body.

请注意，它仍然是=>箭头功能，甚至没有更多的字符。 但是更清楚的是，此函数体中包含三个单独的语句。

Even better:

更好的是：

var fn2 = (x,y) => {
   x = 3;
   y = foo(x + 1);
   return [x,y];
};

To be clear, the proper-arrows rules don't enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

需要明确的是， 适当的箭头规则不会强制实现琐碎的样式差异，例如空格/缩进。 如果要强制执行这些要求，则还有其他(内置)规则。 正确的箭头集中在我认为=>函数定义更实质性的方面。

简明摘要 (Concise Summary)

You and I almost certainly disagree on what makes good, proper => arrow function style. That's a good and healthy thing.

您和我几乎可以肯定的是，什么才是好的，正确的 =>箭头函数样式。 那是一件好事和健康的事情。

My goal here is two-fold:

我的目标是双重的：

1. Convince you that opinions on this stuff vary and that's OK.
   说服您，对这些东西的看法各不相同，没关系。
2. Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.
   使用可配置的工具使您能够制定和执行自己的意见(或团队共识)。

There's really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don't.

争论基于意见的规则确实没有任何收获。 拿走你喜欢的那些，忘记那些你不喜欢的。

I hope you take a look at proper-arrows and see if there's anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

我希望你看看适当的箭头   并查看是否可以使用其中的任何内容来确保=>箭头函数是它们在代码库中的最佳形式。

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It's entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

如果插件缺少一些有助于定义更合适箭头的规则，请提出问题，我们可以讨论 ！ 我们可能会添加该规则/模式，这完全是合理的， 即使我个人计划保持关闭状态！

I don't hate => arrow functions, and you shouldn't either. I just hate uninformed and undisciplined debate. Let's embrace smarter and more configurable tooling and move on to more important topics!

我不讨厌=>箭头功能，您也不应该。 我只是讨厌无知无纪的辩论。 让我们拥抱更智能，更可配置的工具，然后转向更重要的主题！

翻译自: https://davidwalsh.name/i-dont-hate-arrow-functions

功能箭头