Теорема Бома — Якопини — утверждение о структурном программировании, согласно которому любой исполняемый алгоритм может быть преобразован к структурированному виду, то есть такому виду, когда ход его выполнения определяется только при помощи трёх структур управления: последовательностей (sequence), ветвлений (selection) и повторов (repetition).

Теорема была сформулирована и доказана итальянскими математиками Коррадо Бомом (англ. Corrado Böhm) и Джузеппе Якопини (Giuseppe Jacopini) в их статье 1966 года[1]. В статье также описывались методы преобразования неструктурированных алгоритмов в структурированные.

Публикация теоремы была толчком к началу дебатов о структурном программировании. Спустя 2 года вышла статья Эдсгера Дейкстры «Go To Statement Considered Harmful»[2], в которой он критиковал использование оператора GOTO и высказывался в пользу улучшения стиля программного кода за счёт использования структур управления и отказа от других инструкций, управляющих ходом алгоритма.

wiki:Теорема_Бома_—_Якопини

А как вы считаете - можно ли обойтись в программировании без GOTO (Перейти)? И считается ли плохим стилем программирования его использование или нет?

Лучше не использовать, но с осторожностью вполне можно применять.

баян немеряный, ещё с 68го года :-)
Нас этому в 93м учили...

(0) Если упрощает код и понимание кода, то почему бы и нет?

Так

(21) дада, гото в произвольное место кода - то, что нам нужно дли ИИ (половина мистян такие, а модераторы - так вообще все)

гото - просто низкоуровневая замена более красивым конструкциям

А я думаю все равно так

Вполне можно использовать при выходе из ветвлений глубокой вложенности

(10): (применительно к 1С)
* "Выход из циклов многократной вложенности" - есть Возврат, но лучше всего - (19);
* "Переход на точку выхода из функции" - Возврат;
* "Переход в начало процедуры" - рекурсия.

В моей практике ни разу не возникало задачи, которую можно было бы решить только через метки. И раза 3 приходилось переписывать после "пейсателей" код с метками - на код без меток.
Правда, не исключаю, что я просто мало знаю. А посему:

За 18 лет программирования использовал GoTo только на спекртуме. :)

Либо когда шла оптимизация на скорость.

я использую лишь при переборе строк документа и удаление ненужных, т.к. при удалении следующая строка проскакивает необработанной:

~Выбор: ВыбратьСтроки()
Пока ПолучитьСтроку() = 1 Цикл
Если <УсловиеУдаленияСработало> тогда
 Удалитьстроку();
 Перейти ~Выбор;
КонецЕсли;
КонецЦикла;

Какой алгоритм без перехода?

про баян уже говорили?

На 1С ни разу не пользовал. А зачем? )

(128) Я разрешаю

Тем, кто за первый вариант. Вы на ассемблере попробуйте без jmp программу написать. Или оптимизировать рендер в 3Д движке, когда за каждый лишний обработанный полигон в секунду анус рвешь.
Для каждого инструмента есть своя область применения. Не нужно ни злоупотреблять, ни огульно хаять. Надо знать и уметь использовать.

(0) Хорошо хоть теорема, а не аксиома, а то эти "английские ученые" такие ученые... :)

Как только во всех ходовых языках появятся именованные циклы и break/continue [имя], так сразу метки можно будет полностью выбросить - ваять хоронилища состояний частенько напрягает.

а, забыл проголосовать: 2

Причем случай должен быть самый крайний :)
И только в черновом коде , на бело все равно без GOTO перписывать

И конечно-же.

миллионы строк кода были наваяны на фортране в разных его инкарнациях, где использование гоуту являлось вполне обычным делом. И ничего - все работало, летало, плавало. Не то что сейчас.
.
А если взять всякие спецалгоритмы на низкоуровневых языках - там вообще все завязано на сплошные гоуту - по адресам с разными типами адресации...
.
Использование гоуту само по себе ни плохо, ни хорошо. Все определяется тямой в голове того, кто пишет. Сколько встречал гоуту в сторонних разработках 1С - трудностей в принципе не вызывали - были к месту и вполне понятны, не то что некоторые шедевры типа
GOTO М1 //перейти к М1

Уже несколько раз в ветке прозвучало - возврат, прервать, попытка...исключение это самые настоящие гото. Поэтому те, кто пишут нельзя использовать, должны из принципа отказаться от использования этих операторов...

Противники использования вдолбили себе в голову постулаты и не задумываются...

+хожу через парадный

(325) Использовать исключение для обычных действий не фонтан.
- Трудности отладки (все время будет на этом месте спотыкаться).
- Не ясность поведения программы в этом месте.
- Не будет отловлена настоящая ошибка, например в процедуре Сформировать()

По этому я все равно за GOTO, в крайних случаях.

типа так

Иногда кривизна задачи может вполне быть компенсирована кривизной решения.

Когда надо сделать выбор между рекурсией и GOTO, я выбираю GOTO.

как-то так ...
хотя последний раз использовал в 7,7, лет так 8-9 назад

Никогда лично не использовал. Местами видел.

Пистолет с последним патроном тоже должен быть на всякий случай.

Клас, красота кода в УСО 1,3 :)
Глобальный поиск по "Перейти ~" найдено 1175 вхождений :)

"Если есть GOTO, значит это кому-нибудь надо?" (с)

Порой изящнее поставить GOTO, чем городить конструкции IF/ELSE и пр.

если быстро накидать одноразовую обработину по корректировке какой-нибудь ботвы, то применяю, иначе считаю что такой ход выносит мозг

Бывает, что неиспользование настолько усложняет задачу, что проще и быстрее использовать. Хотя сам уже лет 10 не пользовался.

если очень хочется то можно (c)

Когда я был студентом, я оптимизировал выход из рекурсии с помощью GOTO.  Жестко, на ассемблере. Вместо PUSP, POP (все параметры функции передаются через стек) банальноее GOTO и зачистка регистра стеков на расчетное количество вызовов.

Это все равно, что в 1С сделать из тела функции перейти в другую процедуру, наплевав на все параметры.

Препод сначала хотел двойку за такое поставить, но потом оказалось, что мой код побил предыдущий рекорд среди его студентов в 6 раз. Задачка на обход доски шахматным конем,
С 12 секунд до 2 секунд на первом пне 133.

Читабельность конечно стадает, но иногда (очень редко) вместо наворотов кучи флагов/циклов и прочей байды удобнее и быстрее сделать через ГОТО

Использовал метки в обработке подключения торгового оборудования. Связано было с тем, что касса свои порты опрашивает в цикле, и если ВК не попадала, то связь не получалась... Также могла отвалится по тайм-ауту и приходилось переподключаться. Метки позволили избежать многократного повторения отдельных участков кода. Я просто накручивал счетчик ошибок и перемещался к нужной метке для следующего процесса подключения. Код стал прост и понятен, несмотря на использования меток, а было черт ногу сломит!

Не помню, отвечал или нет на голосовалку.

При реальной необходимости использовать можно. Но это возникает чрезвычайно редко. Совершенно не помню, когда использовал последний раз, наверное в школе на gw basic (это было Очень давно :) ).

Если рассматривать язык 1С как язык программирования, то в нём без Goto приходится сильно извращаться, так как:
- Нет стандартного цикла Do {Тело} Loop While {Условие}, а писать While 1=1 ещё более глупо, чем Goto.
- Нет возможности выхода сразу из нескольких циклов. Приходится или писать Goto за пределы цикла (что очень неудобно из-за необходимости вводить метки и задавать им имена) или выносить циклы в отдельную процедуру, чтобы использовать Return (что тоже не всегда удобно и сильно усложняет читаемость).
- Возможность повторения кода с начала после устранения ошибки. Тут или Goto или "вечный цикл" и Continue (не знаю, но применение Goto выглядит более понятным, чем цикл).
Поэтому, если и используется Goto, то нужно писать комментарий, чтобы было понятно, где у нас находится метка.

(506) +1 :)

я один раз использовал - доктор, я буду жить?