Примеры на Яваскрипте, но совет актуален для всех языков программирования, где условия создают вложенность

Проверки условий в коде создают уровни вложенности. Вложенность усложняет работу с кодом: приходится держать в голове все условия и текущий уровень вложенности. Легко запутаться, пропустить «дыры» в логике и сценариях.

Примеры на Яваскрипте, но совет актуален для всех языков программирования, где условия создают вложенность

Чтобы избавиться от вложенности, инвертируйте проверки. Вместо проверки выполнения условия, проверяйте невыполнение. Если условие не выполнено, сразу выходите из функции или пускайте программу по более короткому пути.

Было
function render(data) { if (data.isChanged) { … … … if (data.count) { … … … } } else { this.sync() } }
Стало
function render(data) { if (!data.isChanged) { this.sync() return } … … … if (!data.count) return … … … }

Сложность кода серьёзно уменьшилась. Во время чтения больше не нужно держать в голове все условия.

Приём называется Guard Clause. А мне нравится называть его «вышибалой». Типа, «не прошли фейс‑контроль — дальше не пущу» :‑)

Не могу придумать ситуацию, когда использование Guard Clause повредит коду. Приём, кажется, беспроигрышный. Знаете, когда Guard Clause повредит? Напишите в коментах.

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Отправить
Поделиться
Запинить

Комментарии

Может повредить, если порядок проверок вкупе с их смыслом поменяется. Но это решается разбиением на подфункции.

9 фев 2023

Вышибалой и по‑английски называют! См. «Bouncer Pattern»:
https://wiki.c2.com/?BouncerPattern

И ещё говорят «early return».

9 фев 2023

Вышибала может повредить, когда работает один, без привлечения других паттернов. Например, длинные функции — можно полдня искать причину, по которой что‑то не происходит в хвосте, и только под вечер заметить выход в начале, до изучаемого куска просто ход не доходил. Особенно хорошо это проявляется, когда есть много проверок параметров на входе в функцию — очередь вышибал растягивается на целый экран, сдвигая полезный код куда‑то в хвост, так что при чтении кода мы сначала изучаем то, что он не делает. Множественные точки выхода затрудняют понимание кода, не стоит ими злоупотреблять.

Также вышибала пригоден только при возможности выхода или бросания исключения, проблему других «else» он решить не может, там нужны другие инструменты, начиная с декомпозиции.

Структурное программирование соотносится с образом мыслей — если у нас это, то мы делаем то. Вышибала ломает парадигму — если у нас не это, то нафиг, и если не вон то, то нафиг, и если не так, то нафиг, и только теперь поговорим о том, ради чего мы сюда пришли, но и в середине добавим несколько выходов. Пахнет реинкарнацией «goto». А для чего?

Одна‑две вложенности не представляют сложности для восприятия. От слова совсем. Если код растянулся на несколько экранов, то не вложенность является главной проблемой. И обратите внимание на ООП, где классы образуют такую многоуровневую вложенность, что «if» и рядом не стоял, но никто не предлагает отменить наследование.

Используйте инструменты по назначению. Множественные выходы и множественная вложенность — это инструменты, которые не обладают ценностью сами по себе. Ценность любого инструмента заключается в уместности и умеренности его применения.

14 фев 2023

Рекомендуем другие советы