Я привів свою аргументацію, чому один тернарний оператор зрозуміліший за один IF. І додатково пояснив наслідки — потенційна можливість дописувати у IF-ELSE логіку. А таке зустрічається набагато частіше, ніж складна конструкці з кількох тернарних операторів.

«used too often to create impenetrably complex expressions» . Це так само відноситься до if як і до тернарного оператора. Я згадав у статті GOTO саме для того, щоб показати штучність цього аргументу. GOTO чомусь реалізували, хоча «репутація» у нього значно гірша.
На мою думку причина такого рішення поза технічною сферою. Але пояснення з боку розробників: «мова наша, що хочемо то і робимо» виглядало би нечемно.

Саме так, для того щоб було добре потрібні комплексні заходи. Це лише одна з частин загальної картини.

Судячи з вашого коментарю складна логіка для вас це в першу чергу можливість писати умови. І тому досить логічно, що незрозумілий код і легасі це те чого не можна уникнути.

Я описав непрямі наслідки підходу, щоб якраз такі речі не виникали.
Загалом всі ці «вправи» саме для того, щоб створювати такий проект, який би був зрозумілим, і його можна було б розвивати і супроводжувати. Звісно це одним else не вирішується.
Але так може бути без зайвих «додаткових зусиль». Бажаю цьому навчитись.

Важлива не відсутність else, а саме причина його не використовувати.

А причиною є складність коду яка виникає при цьому. Складність можна оцінити кількістю артефактів які треба одночасно тримати в голові щоб зрозуміти вираз.

Коментатори які у якості аргументу проти тернарного оператора використовують вираз з декількох тернарних операторів допускають туж саму помилку.

Проблема не в самому операторі, а в тому, що якщо об’єднати кілька операторів в одну конструкцію, то код стане складним.

Якщо аналізувати ваш приклад, то за своєю складністю він буде аналогом if else. Штучний приклад у статті можна розбити на три незалежні частини. І це головна його перевага.

Написання коду та архітектура це тільки частина цього питання. Зверніть увагу, автор не дає чіткого визначення що таке складність. Так само ви не знайдете чіткого визначення у Мартіна що таке «чистий код».
Автор приводить багато характеристик складності, але це все наслідки. Причина знаходиться в нетехнічній площині — обмеженності когнітивних функцій людини.

Без розуміння того, що коїться у розробників в голові ви не зможете в повній мірі реалізувати речі описані в цій і в ще багатьох книжках які розповідають як саме треба створювати програми.

DDD — це концептуальний підхід до розробки програмного забезпечення. Але ваше право вважати DDD просто «технікою написання коду».

Важко не помітити коли система не встигає обслужити значну кількість кліентів. Бізнес цілком адекватний, а от кваліфікація розробників була недостатньою, так що не вгадали

Так, вдалим проектуванням класів можна зменшити кількість умовних операторів. Але це ж зовсім інша тема.

Ви дуже вдало згадали про процеси мислення. Це саме те, від чого треба відштовхуватись: як людина сприймає інформацію і які фактори на це впливають.

Холіваром можна назвати тільки тому, що кожен вважає достатнім особистий досвід і кваліфікацію щоб цю тему обговорювати. А варто крім технічних тем цікавитись нейробіологією і когнітивістикою, тоді обговорення буде мати наукове підгрунтя.

Так, це саме те, про що ви згадали: підходи та техніки які дозволяють перезозподіляти та зменшувати складність при розробці програмного забезпечення.

Багато хто про складність згадує, але наврядчи ви знайдете багато конкретики, а що саме треба робити. Описаний підхід — один з елементів боротьби зі складністю.

Я «перекладаю» ваш коментар так: продуктивність важливіша за зрозумілість коду.
Але по перше стаття не про продуктивність заліза.
У переважній більшості випадків бізнесу важливіша продуктивність програміста, а не продуктивність його коду. Грубо кажучи час програміста коштує набагато більше за час серверу. Описаний підхід дозволяє збільшити якість роботи програміста і його продуктивність.

По друге нема значення наскільки швидко працює код, якщо він робить не те що від нього вимагається. :)

Тому у випадку, якщо дуже важлива тродуктивність якогось конкретного шматка коду, повністю з вами погоджуюсь — наявність чи відсутність else не має значення.

Але якщо брати продуктивність команди розробки, особливо в перспективі «довгого» проекту, то описаний підхід повністю виправданий. Це перевірено на особистому досвіді.

Фатальний недолік: більша складність коду. Рахуєте метрики, порівнюєте і нема чого сперечатись.
Зверніть увагу, якою мовою написані приклади за вашим посиланням.
Коли ви програмуєте на C, де самому треба слідкувати за тим, щоб звільнити пам’ять, return посередині коду може призвести до того, що буде текти пам’ять і у вас будуть баги які дуже важко знаходити. У такому випадку один return допомагає полегшити собі життя.

Але у більшості сучасних мовах очищення пам’яті робиться автоматично.
В статті я звертаю в першу чергу на зрозумілість коду, коли не треба намагатись «проковтнути» конструкцію з купою гілок виконання. Коли ти в кожен момент часу маєш справу з невеликим, зрозумілим шматком коду.
Передивіться аргументи наведені у статтях і порівняйте.
Наприклад, простота модифікації. Автор наводить приклад про незакритий файл, а я пишу про те що великий шматок коду з часом стане «легасі».
Обидва по своєму праві, і висновок такий, що треба думати, а не сліпо слідувати якомусь одному правилу.

Реалізуючи DDD ви все одно пишете код. Так що протиставляти DDD і техніки написання коду не можна, повинно бути все в комплексі.
Виділяти окремі функції варто не для того, щоб позбавитись else, а щоб окреслити значну частину коду. І замість купи коду і коментаря типу:
// Наступний блок коду робить те і те
... кілька десятків рядків коду

викликати функцію із зрозумілою назвою.

Не можу погодитися з усіма твердженнями, оскільки вони залежать від контексту. Мій особистий досвід показує: у 90% випадків, переписавши логіку без else, код стає зрозумілішим.
Я не пропоную повністю відмовлятися від чогось, головне — думати, коли це доцільно, а коли ні.

Тема, звісно, холіварна, адже потрібно розуміти, що з чим порівнювати, щоб сказати, що краще, а що гірше. Я вихожу в першу чергу з того, як працює мозок і як простіше сприйняти інформацію.
Аргументи я навів, мій практичний досвід є позитивним. Ну а використовувати підхід чи ні — ваш особистий вибір.

Я описав тільки один з прийомів. Було б добре якби так все просто вирішувалось. Якщо з досвіду: прийшов на проект який був у критичному стані — бізнес був дуже незадоволений станом розробки (критичні прод баги та проблеми з продуктивністю). За 2 роки системної роботи проектом, зі стану «Шеф, фсьо пропало!» проект перейшов у режим коли фічі виходили за графіком узгодженим з бізнесом, критичних прод багів не було, а загальна кількість багів зменшилась. І кількість else по коду теж зменшилась :) Звісно це заслуга всієї команди, але як архітектор я теж свій внесок зробив.

Якби мене запитали яку книгу раджу прочитати розробнику від рівня мідл і вище, це «Ідеальний код» Маконнелла. Фактично кілька книжок по різним темам зібрані разом.

Саме так, якщо компанія це в першу чергу Команда, то і компанія і працівник зацікавлені у розвитку працівника. Якщо якась із сторін починає тягнути ковдру на себе — діла не буде, рано чи пізно співробітництво закінчиться.

Ну в том то и дело, что не сеньйора, а «сеньойра». Сам что-то толковое написать он не мог. Сеньойрной была должность, чтобы продать ёё заказчику.
Ну а хинкали это про внимательность. Я чуть выше анекдот про врачей запостил. Программист однозначно должен быть внимательным к деталям.

Про хинкали и есть анекдот :) Наподобие того, каким должен быть врач.

Профессор в мединституте:
— Cейчас мы с вами, товарищи студенты, пойдём в морг на практику.
В морге:
— Итак! Врач должен быть небрезгливым и внимательным!
С этими словами профессор берёт свой палец суёт в ж#пу трупу и облизывает палец. Все студенты поморщились, но повторили.
— Молодцы! Вы не брезгливые! Но врач должен быть ещё и внимательным! Совал-то я один палец, а облизывал другой
---------------------------------

Сейчас мы товарищи программисты сходим в хинкальню на практику ;) Проверим, насколько вы внимательны ;)