Оператор goto

b

Введение: Оператор, который заставляет сердце биться чаще

Я помню тот холодный вечер в переговорной. Стены давили, проектор мерцал, а на экране висело 800 строк спагетти-кода на Delphi. Клиент, крупный логистический оператор из Германии, потерял данные инвентаризации из-за того, что предыдущий разработчик использовал goto как основной инструмент управления потоком. В тот момент я ненавидел этот оператор. Но жизнь — штука ироничная. Через два года, в другом проекте, именно goto спас нам deadline, когда оптимизация критического участка на TMemoryStream дала прирост скорости в 40%. Эмоции — плохой советчик в программировании. Давайте разберем goto научно, без истерик.

Психология goto: почему мы его боимся и почему используем

Страх перед goto имеет почти религиозную природу. В 1968 году Эдсгер Дейкстра написал письмо «Go To Statement Considered Harmful», и мир разделился на два лагеря. Но в 2026 году, глядя на современный Delphi, мы понимаем: Дейкстра боролся не с goto, а с хаосом в голове программиста. В моей практике было три случая, когда клиенты признавались: «Я написал goto, потому что было 3 часа ночи, кофе кончился, а модуль должен был работать утром». Это не техническое решение — это крик о помощи. Чувство вины и стыд — постоянные спутники разработчиков, использующих goto. Но давайте посмотрим правде в глаза: иногда это единственный способ выйти из ситуации без рефакторинга всей кодовой базы за неделю.

Пять золотых правил (когда goto — это не боль, а радость)

После сотен code review и десятков разборов аварий в проектах, где я выступал как независимый эксперт, я вывел пять ситуаций, когда goto абсолютно оправдан:

Сравнение: что теряет и что приобретает команда

Однажды я работал с банковским проектом на Delphi, где было 1400 goto. Команда из десяти человек ненавидела этот код, но боялась его трогать — боялись уронить расчет процентов. Я провел аудит. Результаты шокировали: 87% goto были эмуляцией циклов и условий. Заменив их на while и repeat...until, мы сократили баги на 64% за три месяца. Эмоциональное состояние команды изменилось: люди перестали бояться заходить в модуль. Но оставшиеся 13% goto мы не тронули — это были те самые «легитимные» случаи. В итоге проект живет до сих пор, а goto используется только в строго регламентированных ситуациях.

Сравните два подхода в управлении ошибками. Без goto:

С goto:

  1. Выделяем все три ресурса
  2. Работаем с блоком A. Ошибка? goto CleanC
  3. Работаем с блоком B. Ошибка? goto CleanB
  4. Работаем с блоком C. Ошибка? goto CleanA
  5. В метках очищаем нужные ресурсы обратным порядком

Второй вариант читается как инструкция, а первый заставляет читателя следить за логическими связями по всему блоку. Эмоционально это колоссальная разница: вместо ментального лабиринта вы получаете четкий маршрут.

Архитектурные решения: как защититься от хаоса

Я настоятельно рекомендую в любом проекте на Delphi добавить в coding standard правило: «goto разрешен только для выхода из глубокой вложенности и единой точки очистки». И добавьте инструмент для статического анализа, который будет подсвечивать каждый goto с комментарием разработчика. Без комментария — code review не пройдет. За годы работы я убедился: запрет на goto без объяснения причин порождает в команде страх и желание обойти правила. Разрешение с четким регламентом, наоборот, снижает тревожность и улучшает качество дизайн-ревью.

Еще один совет из личной практики: если вы видите в коде goto, который прыгает назад (вверх по тексту), — это красный флаг. Почти всегда это можно заменить циклом. Прыжки вперед — более оправданы, так как моделируют исключительные ситуации. Эмоциональная реакция «меня тошнит от этого кода» — часто полезна, но направлять её нужно в конструктивное русло: рефакторинг, а не эмоциональный демарш.

Совет эксперта: как пережить goto и не сойти с ума

За 20 лет в разработке на Delphi я понял одну простую вещь: код — это текст для людей, а не для машины. Компилятору все равно, goto вы используете или if. Он сгенерирует одинаковый машинный код в 99% случаев. Но эмоциональная реакция вашего коллеги, который будет читать этот код через полгода, — вот что действительно имеет значение. Если goto вызывает у него чувство чистого отвращения — ищите другой путь. Если же после чтения кода он пожимает плечами и говорит «ну да, логично» — оставляйте. Доверие к своей интуиции и уважение к чувствам команды — вот главные инструменты инженера, который перерос догмы.

Я видел проекты, где goto был изгнан с позором, и архитектура превратилась в нечитаемые каскады флагов и абстракций. Я видел проекты, где goto был в почете, и код напоминал доску объявлений после урагана. Золотая середина — это регламент, код-ревью и честность перед собой: «Я пишу этот goto, потому что так проще сейчас, или потому что это единственное разумное решение?».

Заключение: goto — это зеркало вашей архитектуры

Почти в каждом проекте, куда меня приглашали как консультанта по «спасению» Delphi-кода, проблемы были не в goto. Проблемы были в том, что разработчики не понимали, когда нужно остановиться и спросить: «А не проще ли переписать этот модуль?». goto не причина, а симптом. Симптом эмоционального выгорания, спешки, нехватки архитектурного видения. В 2026 году, с современными версиями Delphi, поддерживающими анонимные методы и generics, необходимость в goto значительно снизилась. Но полностью отказываться от него не стоит. Держите его в арсенале как скальпель: острый, опасный, но иногда единственный инструмент для ювелирной работы. И помните: самое важное — это не то, как вы пишете goto, а то, как вы спите ночью, зная, что он есть в вашем коде.

Добавлено: 27.04.2026