javascript - 关于 JSLint，它对 for 循环的厌恶，以及尾调用优化

Question

我注意到新版本的 JSLint 不喜欢某些形式的 for 循环。我发现这很奇怪，并开始寻找一些解释。在 JsLint 的 help page 下，你可以找到这个:

The most important new feature of ES6 is proper tail calls. This has no new syntax, so jsLint doesn't see it. But it makes recursion much more attractive, which makes loops, particularly for loops, much less attractive.

还有这个:

jsLint does not recommend use of the for statement. Use array methods like forEach instead. The for option will suppress some warnings. The forms of for that jsLint accepts are restricted, excluding the new ES6 forms.

这两个陈述让我有点困惑。我一直认为 for 循环是最好的循环方式，主要是因为:

1. 一些迭代方法还没有得到很好的支持
2. for 循环比其他迭代方法更少“被听到”

我还在某处读到，像 forEach 这样的方法不能像 for 循环一样被优化，尽管我不确定我是否应该相信这一点。 (可能在 ECMAScript 5 中是正确的？)

因此，支持其他迭代方法的一个论据是它们更具可读性，但是，随着尾调用优化的发挥，它们是否可以像 for 循环一样快或可能更快？

我在这里假设，例如，forEach 可以进行尾调用优化，这是正确的吗？

因此，主要问题是:在 ECMAScript 6 中决定支持 for 循环以外的迭代方法时，尾调用优化究竟如何发挥作用？

也许还有这个:是否可以假设 JSLInt 更喜欢其他迭代方法，因为它们更具可读性，并且因为通过 ECMAScript 6 中的优化，它们可以与循环？我是否正确解释了 JSLint 帮助页面上的语句？

我知道问题应该只有一个主要问题，而我有很多问题；但是，我认为它们彼此之间非常相关，因此我认为回答其中一个可能会回答所有问题。

谢谢，很抱歉发了这么长的帖子!

Answer 1

I also read somewhere that methods like forEach can't be optimized as well as a for loop, although I'm not sure if I should believe that. (Probably true in ECMAScript 5?)

forEach 很难优化，因为你有两个函数调用的开销，回调传递了三个参数(无论你是否使用它们)，另外如果你使用 map 或 filter(但不是 forEach)，您还有创建新数组的开销，而不是就地做事。

So, an argument in favor of other iteration methods is that they are more readable, but, with tail call optimization coming into play, can they be as fast or probably faster than a for loop?

filter 和 map 等的主要论据是它们创建新数组，从而鼓励不变性。另外，它们可以链接起来，看起来不错且可读。如果性能确实成为问题，您可以使用 while 循环或 for 循环，但不要过早优化。

正如我将在下面解释的那样，尾调用优化不会与迭代方法(forEach、map 等)一起发挥作用。

I'm assuming here that, for instance, forEach can be tail-call optimized, is this correct?

forEach 没有优化尾调用(据我所知，这取决于浏览器如何实现它)。尾调用优化仅在函数返回调用另一个函数(即尾调用)的结果时才会启动，例如:

function factorial(n){
   if(n < 2){
     return 1;
   } else {
     return n * factorial(n - 1);
   }
 }

如果你在不支持尾调用的浏览器中运行上面的代码，你会得到一个错误(RangeError: Maximum call stack size exceeded for me in Chrome)一个很大的数字(例如 10000)，因为一次会调用太多函数。尾调用递归意味着 JavaScript 引擎发现您正在递归调用同一个函数，并会相应地进行优化并防止自身超过最大调用堆栈大小。

除非您在 forEach 中的回调使用递归，否则尾调用优化不会帮助 forEach。由于 JavaScript 之前缺乏尾调用优化，因此之前的 factorial 函数将改为使用 while 循环编写。这些递归函数现在首选尾调用而不是循环。

So, the main question is: How exactly does tail call optimization come into play when deciding in favor of iteration methods other than the for loop, in ECMAScript 6?

正如我上面所说，很多人一直在使用循环而不是递归函数，这样他们就不会遇到调用堆栈大小错误。现在，借助 ES6 中的尾调用优化，这些递归函数使用起来更加安全，并且不应抛出调用堆栈大小错误。在这些情况下，现在更倾向于使用递归而不是循环。

And perhaps also this: Is it right to assume that JSLInt likes other iteration methods better because they are more readable, and because, with the optimizations in ECMAScript 6, they can be just as fast as for loops? Did I interpret the statement's over at the JSLint help page correctly?

可读性是函数使用递归而不是循环(使它们更容易理解)和尽可能使用迭代方法(map 来逐值转换数组，而不是而不是 for 循环)。

如果性能成为一个问题，那么您可能想要使用 for 循环或 while 循环，但是有很多 JSLint 不喜欢的东西可能会更快。