Запрещаем говнокод, или полезные плагины для ESLint

И называть лучшие практики, основанные на большом опыте специалистов, "модой" — это такое себе конечно, да.

А какое отношение имеет отказ от базовых конструкций языка для итерирования коллекций к "большому опыту" каких-то там "специалистов"?

они выглядят приятнее

for(const item of collection) // 1
   handle(item); 
for(const item of collection) // 2
   item.handle();
for(const item of collection) // 3
   item.handle(something); 
for(const item of collection) // 4
   await item.handle(something); 
for(const item of collection) // 5
   await item.handle(await some(item.id)); 

collection.forEach(handle); // 1
collection.forEach(item => item.handle()); // 2
collection.forEach(item => { item.handle(); }); // 2 right way
collection.forEach(item => { item.handle(something); }); // 3 
collection.reduce((prev, item) => prev.then(item.handle(something))), Promise.resolved()); // 4  
coll... oh, sh... // 5

Визуально, на мой вкус, конструкции с for-of выглядят куда опрятнее. Глаз воспринимает их мгновенно. Не в последнюю очередь из-за подсветки синтаксиса для const и for и of). К тому же они не располагают писать всё в одну строку (как это делают часто в случае функциональных примитивов, чтобы не прибегать к {}). Не содержат лишнего визуального шума.

А ещё они более дурако-баго-устойчивы. Начинающие и продолжающие часто наступают на эти грабли. Причём иногда это может отнять часы дебага. Тут я имею ввиду:

• доп. аргументы + сокращённые записи (.forEach(method)).
• реакции на return (_.forEach(arr, item => item.handle()).

Учитывая, что forEach не chain-ится, то я часто применяю for-of вместо .forEach в угоду читаемости кода. Но избегаю этого, скажем, если .forEach выступает финальным методом цельной цепочки, чтобы её не рвать попусту.

Пример с forEach хорошо показывает суть линтеров. Это огромное количество друг другу противоречащих правил, почтив все из который чуть более, чем полностью субъективны. Но! Они позволяют вручную настроить тот баланс, который будет удобнее вам и вашей команде. Можно отключить всё лишнее, дописать своё, настроить существующее и т.д… Как ребята из airbnb и сделали. Да и многие, я уверен, делают.

Можно конечно вслепую следовать чужим рекомендациям, "специалистов" с "большим опытом". Но не факт, что вам это хоть что-то даст. Использование каких-то насильственных ограничений без понимания природы этих ограничений мне кажется довольно наивным. Использование этих ограничений исходя из потребностей команды и проекта — может быть очень продуктивным. Настройка eslint-а под вкусы и нужды конкретно взятого тимлида может легко отнять пару дней :)

Видимо всё так, значит это правило уже неактуально и его можно игнорировать.