A
Для сложных reduce возможно еще имеет смысл
Size: a a a
2020 January 10
ST
Alish
Писать функции, у которых весь код это: (map f coll) — это пустая трата времени, тот же Стюарт Сиерра про это писал
могу представить, что случай
я бы смотрел в конкретном случаем, стало ли лучше до или после
если тестируемая функция содержит просто маппинг, то почему нет
(map #(map f %) coll) будет читаться лучше после декомпозициия бы смотрел в конкретном случаем, стало ли лучше до или после
если тестируемая функция содержит просто маппинг, то почему нет
ST
могу представить, что случай
я бы смотрел в конкретном случаем, стало ли лучше до или после
если тестируемая функция содержит просто маппинг, то почему нет
(map #(map f %) coll) будет читаться лучше после декомпозициия бы смотрел в конкретном случаем, стало ли лучше до или после
если тестируемая функция содержит просто маппинг, то почему нет
«если тестируемая функция содержит просто маппинг, то почему нет»
или просто переиспользуется в 33-х местах
или просто переиспользуется в 33-х местах
ST
«если тестируемая функция содержит просто маппинг, то почему нет»
или просто переиспользуется в 33-х местах
или просто переиспользуется в 33-х местах
то есть у тебя «библиотечная» функция делает
(map f coll), а потом ты решил поменять на mapv — не надо выискивать все места в коде, которые делают map fA
«если тестируемая функция содержит просто маппинг, то почему нет»
или просто переиспользуется в 33-х местах
или просто переиспользуется в 33-х местах
В данном случае согласен, хотя на практике обычно есть смысл тестировать f, а не (map f)
A
Если участок кода вызывается во многих местах, это оправданно, но я чаще вижу примеры как у автора поста: эти функции скорее всего нигде кроме как в контексте обрамляющей функции не нужны
A
И происходит разбиение на части как самоцель
A
Я выскажу наверное непопулярное мнение, но по мне вариант «до» был лучше 😁
A
Чуть поправить, разбить еще максимум на пару функций, и норм, всяко лучше того ужаса, который получился в итоге
ST
Мысль простая - функция должна нести законченную смысловую нагрузку. А тело функции может быть каким угодно простым.
ST
Alish
В данном случае согласен, хотя на практике обычно есть смысл тестировать f, а не (map f)
f может быть функцией из внешней библиотеки :-)
A
f может быть функцией из внешней библиотеки :-)
А тестировать map f-из-внешней-библиотеки что даст?)
ST
Alish
А тестировать map f-из-внешней-библиотеки что даст?)
Ты тестируешь свою реализацию. Которая может поломаться из-за изменений во внешней функции, изменений входных параметров, замены map на другое, например mapv
A
Ты тестируешь свою реализацию. Которая может поломаться из-за изменений во внешней функции, изменений входных параметров, замены map на другое, например mapv
Ты прав, хотя по мне это исключение 😊
ST
Alish
Ты прав, хотя по мне это исключение 😊
ST
или вот ещё пример функций, для которых может возникнуть вопрос, зачем их вообще нужно выделять, они же такие простые https://github.com/serioga/advent-of-code-2019/blob/master/src/advent/day_03_1.clj#L106-L114
а они просто отражают выбранную абстракцию для преставления точки на координатной сетке
если рефакторить эту абстракцию, то замучаешься выковыривать соответствующие операции с векторами в коде
а они просто отражают выбранную абстракцию для преставления точки на координатной сетке
если рефакторить эту абстракцию, то замучаешься выковыривать соответствующие операции с векторами в коде
A
В init-amplifiers вполне уместно, без вопросов
A
В остальных – ну хз, я как бы понимаю в теории обоснование и все это круто, но на практике уровень «гранулярности» выбираю другой
A
Где pt-x, pt-y я бы просто написал (let [[x y] ...] где-нибудь на верхнем уровне и be done with it, как говорится
A
С точки зрения перформанса тоже