Box = Order.is_box?(order) && :box flex = Order.is_flexible?(order) && :flex do_lead_time(flex ||

box)

Коллеги, я понимаю как это работает. Но портебовалось время потратить. Как считаете, так писать это норм?
может лучше чуть больше букв но более ясно делать?

По-моему, это довольно красивый maybe стиль

Только мне кажется, что тут неправильный порядок операций, и правильнее было бы type = if Order.has_flexible_items?(order) do :flex else Order.is_box?(order) && :box end

поправил. там взаимоисключающие

Читается ужасно

У тебя просто глаз не привык

Пялюсь минуту и не могу понять чему может быть равно box То же про flex И далее по коду Какой нужно иметь глаз чтобы на этом не спотыкаться?

В эликсире есть 3 стиля обработки исключений, и каждый из них классный. Тут нужно иметь глаз работы с maybe стилем, в эликсире a && b || c это наш местный тернарный оператор, с ним очень удобно жить

По ссылке просто пиздец как хуёво. Тут ты вообще не делаешь вид что тебе не плевать на ошибку, если у тебя nil, то что-то сломалось и тебе поебать. Даже это предложение требует усилий на прочтение. Это одно предложение или два? Как вообще его правильно понять? С пятой попытки прочитать наиболее правдоподобный вариант - это Тут ты вообще не делаешь вид что тебе не плевать на ошибку. Если у тебя nil - то что-то сломалось, и тебе поебать. Почему б сразу не написать так чтобы читалось без запинки? Похоже, у автора это системное. Как бы ок, подход когда нужно высирать тонны кода в секунду тоже имеет право на жизнь, но не надо говорить что a && b || c - это ОК ДЛЯ ЧТЕНИЯ ПРОСТО ГЛАЗ НЕ ПРИВЫК. Это write-only код со всеми вытекающими.

Во-первых, автор это я. Во-вторых, a && b || c нормально читается, я серьёзно. Тернарные операторы используются и в C/C++ и в JavaScript, к этому просто надо привыкнуть

что вернёт true && b || c ?

b

А, ну в этом случае так, да

интересно, а если оба false тогда что

Только вот этот стиль с && и || часто ведёт к тому, что у тебя выражения начинают возвращать что-то неожиданное, потому что люди не возвращают какое-то значение либо nil, а начинают мешать все типы, и тебе где-то на другом конце надо обрабатывать два типа NULL (nil и false). А потом ещё и огребать ошибки в непонятных местах, потому что границы разных кусков логики начинают протекать друг в друга.

Ничего не понял

with {_, false} <- {:box, is_box?(o)}, {_, false} <- {:flex, is_flex?(o)} do {:error, :unknown} else {type, true} -> do_lead_time(type) end

Это, наверное, худшее что я видел

терпите

хехе)

самое читаемое решение

Основной путь получается в ветке else :(

Не обязательно, возможно просто таким образом пытаются различные виды ошибок по-разному обрабатывать. Но все равно какашка. Уж лучше отдельную функцию сделать

Ну смотри. У тебя тут выделяется два кейса: :flex и :box. Ты их обработал такой, но понимаешь, что должен быть ещё кейс. А что это такое? nil? false? В данном кейсе, понятно, что мы ожидаем false, но если такого кода становится много, ты уже не знаешь, чего ожидать. Плюс, ты действительно мог ввести дополнительный идентификатор — :regular, который бы обозначал другие кейсы, но из-за стиля у нас такие неочевидные повороты.

Ну вот nil обычно означает кейс типа "здесь может быть не то что ты хочешь", а не какой-то логический кейс

согласен. Дело не в количестве символов, дело в легкости понимания. Банальшина, но мы пишем код для людей. Вариант с cond самый читаемый и понятный, плюс к тому же открывает кейс когда он и не flex и не box

может быть флекс