Функция reduce

только логичнее делать сравнение не <0, а ===-1

Рад, что вам понравился этот пример. Вообще, ни он, ни ваш код не нужны, т.к. можно просто использовать библиотечный аналог (о чём я упомянул в статье). Пример чисто синтетический и он реализует не «бизнес-логику», а библиотечную функцию, спека которой заморожена, и, следовательно, это код не подвержен изменениям. Поэтому я позволил себе использовать джедайский подход.

По вашему варианту (если предположить, что это всё таки БЛ) можно сказать, что он более читаемый, но я бы ещё обрамил ветви в фигурные скобки, потому что они имеют свойство расширяться, и тогда скобки уже необходимы. А также, я бы разнёс на разные строчки условие и ветвь then. Это сделает дифф чище, если условие или одна из ветвей будет меняться по отдельности. Ну, и как уже заметили, лучше использовать сравнение с -1, потому что это флаговое значение.

А вообще, мне интересно померить скорость самого подхода с reduce. Возможно он не так быстр, как простой плоский цикл, и стоило бы придраться именно к этому :)

Я не то что бы «за» этот способ, но чего это вдруг бинарные операции стали «экзотическими», как и принцип работы с запятой?

Абсолютно не соглашусь с вами, во всем, за исключением действительно странного примера с тернарным оператором, тернарность которого тут и правда не нужна. Я убежден, что крокфорданизация JavaScript преследует немного иную цель, нежели писать все согласно заветам, и эта цель — единообразие.

Если команда решает, что нужно по возможности использовать тернарки, то нужно следовать этому. Если команда решает, что нужно использовать лексему `~[].indexOf()` для проверки вхождения — нужно этому следовать. Если в команде принято иначе — нужно придерживаться общих правил.

В JavaScript есть некоторые «неудобные конструкции» — hoisting, автоподстановка точки-с-запятой, которая не срабатывает на строках оканчивающихся или начинающихся на скобочки и операторы, которые могут быть как унарными, так и бинарными. Но все это не значит, что этими штуками грушновато пользоваться. Я считаю это глупым. Посмотрите, сколько команд не используют точку с запятой, посмотрите сколько дейстивительно великолепных JS-разработчиков пишут вызов функций через тернарные операторы. TJ Holowaychuk, Isaac Schlueter, да у каждого состоявшегося разработчика есть предпочтения, и это не просто нормально. Это отлично!

Совершенно не имеет значения, какие лексемы и практики языка использовать, а какие нет, главное, делать это единообразно в рамках всей команды. Если вы не знакомы с побитовым оператором `~` — это значит, что нужно разобраться с ним. Если вы знакомы — в чем проблема запомнить лексему? Научиться практикам команды для начинающего разработчика практически тождественно тому, чтобы запомнить стайлгайд, возможность разобраться с острыми углами стайлгайдов — это комплимент, который вам сделала команда.

Для примера сравните такие конструкции:

function (rights) {
  return ~[rights].indexOf('write')
    ? fs.writeFile(...)
    : next(throw new Error());
}

function (rights) {
  if ([rights].indexOf('write') !== -1) {
    return fs.writeFile(...)
  } else {
    return next(throw new Error());
  }
}

function (rights) {
  if ([rights].indexOf('write') !== -1) {
    return fs.writeFile(...)
  }
    return next(throw new Error());
}

По-моему, нет никаких причин, не писать так, как в первом примере, если а) У вас нет желания научиться в тернарные и битовые операторы б) У вас нет договоренности с командой.

В любом случае, указывать другим как писать код — это весело, но нужно иметь свою голову на плечах и понимать причины тех или иных гайдов. А читаемость кода — я понимаю исключительно как единообразный стиль, остальное — комформизм.

да, занятно. хотя иногда кажется: ну что там еще можно сказать про js. а оказывается есть что.

Да, я помню, как Гвидо это говорил, но забыл поискать ссылку. Я хотел добавить это в статью, в пункт про Python. Тем более есть на хабре, спасибо.

Тем самым он еще больше внес путаницы в язык.

Добавил в статью.