關(guān)于Airbnb的《Iterators and Generators》eslint規(guī)則的疑惑

1. 首先map() / every()方法可以保證數(shù)組的不變性，而for完全取決于你寫代碼的人。
2. 語義規(guī)則很明顯，知道你要干嘛。
3. 這些方法使用的算法實現(xiàn)都比較快（可能不如你定制的實現(xiàn)快但足夠通用），其次引擎本身還會對他進(jìn)行優(yōu)化。
4. 當(dāng)然使用這些方法未必能精確控制，但是通常并不需要（基本都有對應(yīng)應(yīng)用場景的方法）。

樓上說的挺好的了，不知道為啥有人點了個反對，我補(bǔ)充一些：

• 之前在重構(gòu)一次公司項目的時候，發(fā)現(xiàn)之前的程序員大概就是 for..in for..of 一把梭，這種代碼看多了，就會變得很懵逼，因為你并不知道這個 for 循環(huán)到底在干什么，也就是樓上提到的第二點
• 有時候遍歷需要加一些過濾邏輯，然后再 for 循環(huán)語句塊中就會有大量的 if..else，進(jìn)一步加深了懵逼程度
• 另外 for..in 有一個問題就是，它會列舉所有可枚舉的屬性，這樣一個對象實例在創(chuàng)建時，繼承于原型的可枚舉屬性也會被遍歷到了，因此 if(foo.hasOwnProperty) 在一些情況下都要寫，很麻煩
• 使用 map、filter、reduce 等方法與等效的 for..in 或 for..of 在結(jié)果上是相同，但是編寫代碼的思想是不同的，前者是面向邏輯，而后者是面向過程
• 面向邏輯是函數(shù)式編程的一個特點，如果你稍微了解一些函數(shù)式的東西，會有一個很重要的純函數(shù)的概念（具體是什么可以網(wǎng)上查一查），一般而言，業(yè)務(wù)都是復(fù)雜的，大型應(yīng)用編寫難度高很大程度上因為業(yè)務(wù)復(fù)雜度高，如果我們可以保證實現(xiàn)業(yè)務(wù)的代碼，竟可能的具有純函數(shù)的特性，那么可以有效降低項目復(fù)雜度，降低風(fēng)險

以上是關(guān)于你問題描述中的第一點的答案，下面說一下第二點。

如果你使用 map 或 forEach 想提前跳出的話，可以這樣：

try {
arr.forEach(function(e){
  // todo something...
  throw new Error('foo')  
})
} catch(e) {}

雖然方法偏 hack，但確實有用。

不過話說回來，使用這些方法講究的是映射關(guān)系的抽象，如果將邏輯進(jìn)行合理抽象，其實多做幾次循環(huán)的時間損耗在性能上真的微不足道，相反，如果利用一些函數(shù)式的工具庫將這些業(yè)務(wù)代碼進(jìn)行組合（compose），反而可以提高性能。

題主有時間可以了解一下 ramdajs 這個工具庫。