По поводу vim: замена символа (индекс в тесте) — r <символ> Переход до конца блока — %. Таким образом, например, можно быстро вырезать блок: встаёшь на строчку с блоком, v, end, %, d Двигать курсор вперед до символа — t <символ>, назад — T <символ>.
Чувствую, что скоро ИИ также будет друг другу объяснять как устроены нейроны у людей: «На следующем занятии мы разберем как эти кожаные мешки учатся говорить и почему это происходит так долго, а не за пару часов»))
Всё было превосходно до момента как решение мусора ограничилось лишь первым вызовом… а что если мусор будет дальше? разве должно быть обнуление? а так и будет: sum(1)(2)()(4); // 1 // 3 // 0 // 4 Имхо, необходимо и n обрабатывать, и в случае с кратким написанием функции возврат должен быть таким return (n) => sum(a + (parseInt(n) || 0)); // 1 // 3 // 3 // 7 Могу быть не прав в правильности решения, не js-ник…
замена символа (индекс в тесте) — r <символ>
Переход до конца блока — %. Таким образом, например, можно быстро вырезать блок: встаёшь на строчку с блоком, v, end, %, d
Двигать курсор вперед до символа — t <символ>, назад — T <символ>.
В реальной работе — морока такая эти тесты писать.
Поэтому многие их не пишут. Или пишут тяп-ляп. Потому что проверь то, проверь это. Еще и деструктивные проверки.
Но тесты писать — полезно и правильно. Чтоб Боинги потом не падали из-за ошибки в программе.
sum(1)(2)()(4);
// 1
// 3
// 0
// 4
Имхо, необходимо и n обрабатывать, и в случае с кратким написанием функции возврат должен быть таким
return (n) => sum(a + (parseInt(n) || 0));
// 1
// 3
// 3
// 7
Могу быть не прав в правильности решения, не js-ник…