Школа
Веб-разработка

Guard Clause. Избавляемся от вложенных условий в программировании

9 фев 2023
👁 6398   🗩3
Веб-разработка

Guard Clause. Избавляемся от вложенных условий в программировании

9 фев 2023
👁 6398   🗩3
Игорь Петров
Разработчик, преподаватель Школы бюро
Полезно
 9
9
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать

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

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

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

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

Было
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
9
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

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

Владислав Загревский

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

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

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

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

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

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

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

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

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