Человеко-читаемый JavaScript: история о двух экспертах

[mayorovp]

Далее мы вообще убрали стрелочную функцию. Используем тот же синтаксис, что и раньше, но теперь предпочли ключевое слово function. […] Этот код пространнее, чем наше первое определение, но так ли это плохо?

Это очень плохо. Одна строчка кода превратилась в пять. А если в этой строчке будет не одна операция map, а, скажем, map и filter — то эта одна строчка превратится в десять. Десятикратное увеличение строк кода на пустом месте — определенно не то, что способствует читаемости кода

[sultan99]

Когда вижу в коде `let`, у меня повышается внимание на эту переменную и жду когда автор кода начнет ее изменять. Приходится заглядывать каждые `if else`, чтобы понять когда и как он ее меняет, но когда видишь код целиком написан на `let/var` и думаешь ну хренов эксперт из дикого запада.

Давно уже пора привыкнуть этим стрелочным функциям, опциональным/тернарным операторам:

const bob = users.find(user => user.name ===`Bob`)
const message = bob?.age > 21 ? `Can buy beer` : `Not, yet`

И если джун, не понимает, что тут написано, то отправляем его учить матчасть и не адаптируем код под него. Код хорош тогда когда он краток и понятен, а вот чтобы было понятно нужны знать азы, по любому.

[Rsa97]

Когда вижу в коде `let`, у меня повышается внимание на эту переменную и жду когда автор кода начнет ее изменять.

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

[CoolWolf]

Всё решается настроенной связкой eslint + prettier и набором правил для них под кодстайл проекта

[rjhdby]

Всю статью можно было заменить одной цитатой Мартина Фаулера.

Любой дурак может написать код, понятный компьютеру. Хороший программист пишет код, понятный человеку.

[andres_kovalev]

Классические объявление функции и функциональное владение идентичны определению стрелочной функции только в случае контексто-независимых функций. Например, в данном случае тип функции имеет значение:

const instance = {
  id: '...',
  filter(items) {
    return items.filter(item => item.id === this.id);
  }
};

[Keyten]

При всем потенциале оператора расширения, символ его не самоочевиден

Половина статьи из серии «а что если код будет читать незнакомый с JS человек, и ему будет непонятно». Довольно сомнительная мотивация к увеличению кода.

Разница между этими двумя конструкциями

let multipliedByTwo = arr.map(el => el * 2);
let multipliedByTwo = arr.map((el) => el * 2);

в том, что последняя активно стремится к parenthesis hell (хотел изобрести этот термин ради этого комментария, но он оказался уже есть).

Даже уже этот вариант гораздо менее читаем, потому что ты воспринимаешь стрелочную функцию не как одно целое, а аргументы и тело отдельно. Я уже не говорю о том, что через пару лет на этом самом месте ты встретишь какое-нибудь ))))) и будешь пересчитывать, через сколько скобок тебе нужно поставить Enter, и какая к чему относится.

Убирать же стрелочную функцию и вовсе максимально сомнительное решение, ибо они как раз и созданы для того, чтобы понимать с первого взгляда «тут умножение на два», а не плодить в интерпретаторе в уме сущности «тут новая функция, пойдём смотреть, что у неё там в теле».

Как видите, очевидного ответа здесь нет.

Он есть. Если твоя стрелочная функция умещается в одну строчку, вроде timesTwo, имеет смысл её инлайнить (даже если она используется 10 раз подряд), потому что тогда тебе не придётся прыгать по коду с вопросами «а что делает эта функция» — да, даже если она объявлена буквально строкой выше. Иногда имеет смысл выделять, если код становится с этим гораздо более лаконичным.

Если функция используется несколько раз, и при этом содержит логику, не очевидную с первого взгляда, имеет смысл её отделять отдельно. Если функция большая, то имеет смысл её отделять, если в основной функции и так много логики, и нарушается правило «делать функции поменьше и поатомарнее».

Что касается деструктурирующего синтаксиса, я не должен его применять только потому, что могу применить

Так всё-таки почему? Потому что не знающие JS коллеги не поймут?
Этот синтаксис лаконичнее и проще. Может, мне ещё вместо { abc } использовать { abc: abc }?

const nums = [...arr1, ...arr2];
const nums = arr1.concat(arr2);

Первое — очевидно с одного взгляда. Второе — нужно прочитать строчку до concat, вспомнить, что arr1 это массив, посмотреть, с чем конкатенируется, объединить в один смысл в голове. Ещё один совет из серии «как сделать ваш код менее читаемым».

[mayorovp]

Так всё-таки почему? Потому что не знающие JS коллеги не поймут?

Потому что node = exampleObject.node читается проще чем ;({node} = exampleObject).

[Keyten]

const { node } = exampleObject;

читается проще обоих вариантов, поэтому очевидно, что нужно использовать его.

[mayorovp]

Лучший-то лучший, да вот иногда так случается, что переменная в текущем скоупе уже объявлена, надо лишь присвоить ей значение.

[Keyten]

В таком случае очевидно, что лучший вариант

node = exampleObject.node

Непонятно, к чему всё это. «Не используйте деструктуризацию, потому что её можно использовать не всегда»?