Намедни поинтересовались моим мнением по поводу этого куска кода: В том чятике разгорелся спор какое решение лучше, императивное или функциональное. А я хочу сказать, что если решение записывать так как на снимке выше, то они оба плохие. Для тех кто имеет опыт рецензирования кода это очевидно. В промышленном коде главное понятность, все остальные параметры стоят на втором месте. Даже корректность. Если в коде есть ошибка, то в понятном коде она будет найдена быстрее. А если код работает верно, но никто не может понять почему, то во-первых, под сомнением его корректность во всех ситуациях, а во-вторых, этот код не поддаётся изменениям, а они порою случаются в любой развивающейся программе.

Но при чём здесь фраза которую я вынес в заглавие? А при том, что во всех случаях перед программистом ставится задача писать код максимально понятно. Исключением служит только олимпиадное программирование, но это особый случай, который можно смело проигнорировать (несопоставимы объёмы "промышленного" и "олимпиадного" кода, и даже языки программирования все создаются для промышленного применения, но не для решения олимпиадных задач, если только сам язык не является частью задачи). И вот понятность кода со снимка далека от максимальной. Как же записал бы решение задачи я? Вы, кстати, поняли из того фрагмента в чём состояла задача? Итак, требуется найти медиану для двух отсортированных векторов целых чисел. Первое исправление: зачем возвращать медиану как дробное двойной точности? Медиана массива целых чисел будет либо целым числом, либо, на практике, отличаться от целого на 0,5. Нам так важно записать 0,5 именно с двойной точностью? Если контракт/интерфейс/трейт не треует, то одинарной точности более чем достаточно.

Второе исправление: зачем в названии использовать слово "find"? Важно прежде всего что функция возвращает, а не как это число получается. Поэтому библиотечные функции называются len() и last(), а не find_len() и get_last().

Ну и наконец главное, вы можете видеть, что ключевая часть моего решения записана в одну строчку, и результат выполнения этой строчки понятен без пояснения. Реализацию используемых функций я приводить не буду, она очевидна и в общем совпадает с той что на первоначальном снимке. Моё решение не идеально, в нём даже не используется отсортированность передаваемых векторов. Вероятно моё решение потребляет больше памяти и машинного времени. Но это является проблемой только если предъявляются соответствующие требования. Если бы в формулировке задачи говорилось, что тестовая система будет проверять функцию на векторах хренолиардной длины, а отработать всё должно за 1 минуту, то и решение должно было бы быть другим.

Я не отрицаю, что требования могут быть скрытыми. Начиная с упомянутого выше требования понятности. Интерфейс должен быть хоть в какой-то мере отзывчивым, архитектуре лучше бы быть хоть в какой-то мере расширяемой, но это вторично (если только явно не обозначено). Задача инженера — решить поставленную задачу, простите за каламбур, а не додумывать её за начальника, владельца бизнеса или заказчика. Если хочется — можно задать уточняющие вопросы. Нужно помнить, что заказчик или бизнесмен может иметь сильно отличное представление о назначении программы, о допустимых сроках и бюджетах. Я не отрицаю, что хорошие инженерные решения лучше плохих, что существует инженерная красота, что тяп-ляп (и в продакшен) — плохой подход, но каждый раз задерживая выпуск изделия для поиска лучшего решения инженер тратит не свой бюджет, и может задерживать производственные цепочки о которых он даже не подозревает. Любая разработка сверх технического задания это, как это по-русски, overengineering. Потому что настоящего инженера устраивает любое решение удовлетворяющее техническому заданию.