Почему goto это плохо

goto — добро или зло?

Интересует насколько плохо юзать goto? Есть ли смысл его избегать? Вредит ли это както генерируемому компилятором коду?

#1
2:41, 25 авг 2007

Вот я тоже люблю goto в код вставлять 🙂

#2
2:41, 25 авг 2007

Считается, что:
его использование ухудшает читаемость/восприятие кода сильнее, чем break; или return; в середине функции;
нет острой необходимости в его использовании;
он плохо вписывается в концепцию языка 🙂
Поэтому и ругают/избегают/запрещают.
Впрочем, этот вопрос, скорее всего, религиозный.

#3
2:44, 25 авг 2007

> Интересует насколько плохо юзать goto?
Как правило читаемость кода сильно ухудшается.

> Есть ли смысл его избегать?
goto бывает действительно нужен очень редко. Почти всегда, если хочется написать goto, надо немного подумать и найдется лучшее решение.

> Вредит ли это както генерируемому компилятором коду?
Нет.

#4
2:44, 25 авг 2007

>его использование ухудшает читаемость/восприятие кода

#5
2:45, 25 авг 2007

goto вредит скорее пониманию кода. Но есть некоторые случаи когда без goto не обойтись, к примеру если надо быстро выйти из череды вложенных циклов.

#6
2:47, 25 авг 2007

SunnyDay
говорю же вопрос религиозный 🙂 много людей обратного с тобой мнения

#7
2:49, 25 авг 2007

Отвечаю) Компилятору это никак не «вредит»:) В большинстве случаев код с goto и с обычными if/while оптимизируется ровно в одно и то же. Есть, правда, одно исключение, когда использование goto помогает избавиться от геморроя; это так называемые crossing-loops:

if ( . ) goto label2; . label1: . label2: . if ( . ) goto label1;

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

Тем не менее, я не советую использовать goto. Просто из-за того, что если меток и переходов будет слишком много, тяжело будет читать и тестировать код.

#8
3:19, 25 авг 2007

наиболее часто применяемое по делу goto сейчас — это переход по ошибочной ситуации к общему блоку очистки ресурсов.

int f( ) < int result = -1; void *p1 = NULL; void *p2 = NULL; p1 = malloc( 10); if ( !p1) goto ERROR; p2 = malloc( 20); if ( !p2) goto ERROR; . if ( что-то не получилось) goto ERROR; . result = OK; ERROR: if ( p1) free( p1); if ( p2) free( p2); return result; >

В С++ типично всё живёт на деструкторах и поэтому goto не нужен, но в старом добром C такой goto незаменим.

void f( ) < std::vectorint> p1( 10); std::vectorfloat> p1( 20); . >

Ещё — выход из вложенных циклов. Часто это звоночек о том, что лучше эти два цикла вынести в функцию.

bool is_found = false; for ( int i = 0; i  n; ++i) for ( int j = 0; j  m; ++j) if ( a[i][j].x == 7) < is_found = true; goto found: > if ( is_found) . else .

bool find( ) < for ( int i = 0; i  n; ++i) for ( int j = 0; j  m; ++j) if ( a[i][ j].x == 7) return true; return false; > . if ( find( )) . else .

Есть ещё некоторые случаи, но они редкие-редкие.

#9
3:24, 25 авг 2007

Executor
программирование — это искусство компромисов. скорость-используемая память, скорость-размер кода. так БЫЛО.
потом памяти стало много, процессоры стали быстрыми и на них (память и скорость) перестали обращать внимание. не всегда и не везде — но по большей части. так ЕСТЬ. зато появился другой критерий — ПОНЯТНОСТЬ.
а заодно — куча лже-критериев (это мое такое имхо) — вроде «соответствия той или иной парадигме программирования». сначала этой парадигмой было структурное программирование. потом — объектно-ориентированное. и так далее.

вопрос ведь не в том, хорошО ли само пе себе то или иное средство — вопрос как им пользоваться. если по делу — то никто не кинет камень, кроме упертых фанатов того или иного стиля. а если не по делу — то комментарии, имхо, излишни. но это касается не только гоуту, это относится вообще ко всему.
так что- отвечая на вопрос — при правильном использовании — гоуту эффективен, и пойдет коду только на пользу. а при неправильном. СИЛЬНО хуже не станет — с точки зрения кода. хотя это тоже может зависеть от самого кода.

вообще, мои персональные наблюдения за тем, что на уровне ассемблера порождают компиляторы (за последние 10 лет) постепенно привели меня к нехитрому приему —
НЕ МЕШАЙТЕ оптимизатору сгенерировать хороший код. не надо сильно считать высокоуровневые инструкции — никто, кроме компилятора, не скажет во что это выльется.
тупой пример —

int a[10000]; < for ( int i=0; i10000; ++i) a[i] = 0; >

ни пол-раза не оптимизированный цикл. но запросто развернется во что-то вроде
xor eax, eax
mov ecx, 10000
mov edi,
rep stosd

а гоуту. иногда — в очень специальных случаях — он действительно может быть эффективен. но мне за последние 10 лет не довелось написать его ни разу.
может, у меня какие-то задачки не те?

#10
4:13, 25 авг 2007

< SameComplexClass some( ); goto label2; label1: // Чему равно some? > SomeUberClass foo( ); label2: // Чему равно foo? goto label1; >

Последний раз использовал в бейсике, в конце 90-х.

#11
7:14, 25 авг 2007

Если в результате применения goto код получается: компактнее, эффективнее и легче читается, то почему бы и нет.
Я сам использую goto со скоростью примерно 1 раз в 2-3 месяца — как правило, в сложных ситуациях, когда требуется выход на финишный блок или наоборот, рестарт функции с другими параметрами.

#12
11:14, 25 авг 2007

Ясно, спасибо за разъяснения.

GOTO or not GOTO вот в чём вопрос

«Спор возможен там, где истина закрыта. В бесплодных спорах можно бесконечно обсуждать, что в комнате находится закрытой дверью. Но стоит дверь открыть, и ясно станет всем и спорить не о чем, коль каждый истину увидеть сможет»

Статья посвящается Зацепину П.М., выдающемуся инженеру Алтайского государственного университета, под чьим чутким руководством многие студенты, включая автора статьи, постигали магию инженерного творчества.

Введение

Спор о возможности использования в программах оператора GOTO ведётся уже очень давно (официальным его началом признана статья Дейкстры «О вреде оператора GOTO», опубликованная в 1968 году [2]). Через три года мы будем праздновать 50-летний юбилей этого спора. Это хороший повод, чтобы наконец-то «расставить все точки над i» и прекратить спор.

Цитата в эпиграфе выбрана неслучайно. Она в точности отражает текущую ситуацию в споре про GOTO. В нашем случае «комната за закрытой дверью» – это понятная всем постановка задачи. Пока, к сожалению, такой постановки задачи озвучено не было, поэтому споры и не угасают. Противоборствующие стороны спорят хоть и о схожих, но всё-таки о разных вещах, поэтому и не могут найти компромисса.

Давайте займём в этом споре нейтральную сторону, и беспристрастно во всём разберёмся. Рассмотрим доводы «противников» и «защитников» оператора GOTO и решим, «кто из них прав, а кто виноват».

Почему ведутся споры

Как уже было отмечено выше, споры о возможности использования в программах оператора GOTO ведутся из-за отсутствия понятной всем постановки задачи. Грубо говоря, одна из сторон доказывает, что дерево плавает, а другая, что кирпич тонет. Естественно, что при такой постановке каждая из сторон уверена в своей правоте и будет вечно её отстаивать.

Противники GOTO уповают на правила хорошего тона. Именно здесь и спрятан ключ от «закрытой двери», т.к. существуют, по крайней мере, три правила хорошего тона: «хороший тон в структурировании», «хороший тон в быстродействии» и «хороший тон в компактности», но противники GOTO учитывают только один из них.

Защитники GOTO уповают на требования заказчика, где, среди прочих не редко встречаются пункты, связанные с быстродействием и компактностью программы. При такой постановке одним правилом хорошего тона не обойтись – приходится искать компромиссное решение. В результате такого решения в программе иногда и появляется оператор GOTO.

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

Озвученная точка зрения весьма поверхностна, т.к. не учитывает деталей спора. Чтобы сформулировать объективную постановку задачи, необходимо рассмотреть аргументы и контраргументы каждой из сторон. Этим мы сейчас и займёмся. Жирные буквы З – это аргументы защитников GOTO, а жирные буквы П – это аргументы противников GOTO.

Доводы «противников» GOTO

1. Использование GOTO – плохой тон.
З: Это неаргументированное заявление, поэтому спорить здесь нет смысла.
2. Самый плохой тон – возвращение с помощью метки назад.

З: Действительно, так использовать GOTO нельзя, так же как нельзя его использовать и для перехода в другой блок области видимости – можно или оставаться в текущем, или выходить из него. Если следовать двум этим правилам, то использовать GOTO можно.

3. GOTO – избыточный оператор. Его легко можно заменить циклами и условиями.

З: Если на то пошло, то из языка можно выкинуть практически все операторы.

С точки зрения структурного программирования из языка можно вообще выкинуть все операторы, оставив только while и оператор присваивания. [1] В таком случае программы будут хоть и объёмными, но понятными. Если бы на практике внимание уделялось только структуре программы, то такой шаг был бы обоснованным, но в реальных задачах есть ещё требования на быстродействие и компактность, а этого одним оператором добиться невозможно.

GOTO – признак не кривизны кода, а кривизны языков, в которых без него порой никак (C, C++, C#, Pascal, Java, etc) и кривизны профанации под названием «структурное программирование» с его т.н. «циклами с предусловиями», «циклами с постусловиями» и «ветвлениями», которые являются не элементарными конструкциями, а типовыми паттернами, в которые задача не всегда удобно ложится.

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

4. Вирт и Дейкстра говорят, что GOTO это плохо. [2, 3]

З: Авторитетные мнения достойны внимания, но то, что говорят авторитеты, не есть истина в последней инстанции. Недаром в учёной среде бытует фраза «Если уважаемый учёный говорит, что «это сделать возможно», то он скорее всего прав, а если говорит, что «это сделать невозможно», то скорее всего не прав».

Есть и такие авторитеты, которые высказываются в пользу GOTO, например, Дональд Кнут [4], Фредрик Брукс. [5] Но при решении задачи более целесообразно опираться не на мнение авторитетов, а на здравый смысл.

5. GOTO аннулирует многие возможности компилятора по оптимизации управляющих структур, из-за чего код становится медленней и объёмней. [2]

З: Эта проблема никоим образом не связана с GOTO, т.к. оптимизация производится на уровне машинных кодов. Да, GOTO вставляет в машинный код инструкцию перехода, которая препятствует оптимизации кода, но те же самые инструкции вставляют и условный оператор, и операторы цикла.

Доводы «защитников» GOTO

1. Группа взаимоисключающих условий.
Пример кода.

if(objectA.nValue == objectB.nValue) < . goto END; >if(objectC.nValue == objectD.nValue) < . goto END; >if(objectE.nValue == objectF.nValue) < . goto END; >END: . 

if(objectA.nValue == objectB.nValue) < >else if(objectC.nValue == objectD.nValue) < >else if(objectE.nValue == objectF.nValue) < >… 

П: В данном случае GOTO структуру программы не портит, но в таком построении нет практической необходимости, т.к. то же самое можно организовать через if/else.

З: Заменить приведённый код на if/else можно только в том случае, если перед завершением не выполняется дополнительных операций.

П: Дополнительные операции можно вынести в отдельную функцию и вызывать её в каждой ветке.

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

П: Отдельную функцию можно оформить в виде inline-функции, тогда на быстродействии это никак не скажется.

З: Но тогда программа будет занимать больше памяти. А это тоже в некоторых случаях может противоречить задаче.

В результате этого спора во многих языках были введены процедуры завершения и механизм структурной обработки исключений. Эти инструменты работают немного медленнее GOTO, но более наглядны, поэтому для большинства задач их вполне хватает. Но, опять же, существуют задачи, где критично и это «немного», – в них использование GOTO видится целесообразным.

2. Принцип вселенской причинности – если где-то есть GOTO, значит он там нужен.

Новый язык появляется не с бухты-барахты. Перед разработчиками языков программирования стоит непростая задача – удовлетворить все запросы программистов, и учесть общепринятые парадигмы. Абсурдно предполагать, что в языке будет реализована концепция, которая никому не нужна. Если в качестве примера рассмотреть Си, то вообще все вопросы отпадают, т.к. при анализе языка складывается такое ощущение, что за каждый новый введённый в язык оператор разработчики должны были заплатить из своего кармана по 5000 долларов… а оператор GOTO там есть.

3. Выход из множества циклов одновременно.
П: Классический аргумент. Против него не поспоришь.
4. Конечные автоматы (пример кода).

state_1: switch (signal) < case 1: goto state_5; case 2: goto state_10; case 3: goto state_8; >state_2: switch (signal)

 // Достойных реализаций без GOTO не обнаружено. 

5. Ещё один пример.
Пример кода.

for (int i=0;i // some code > next2: // some code> next1: // some code > 

inline void doSomeActivityInFor() < for(int i=0;i// some code > // some code > inline bool some_condition3(i,j) < for(int k=0;kreturn false; > 

П: Приведённый код выполняется с той же скоростью и занимает столько же памяти, что и код с GOTO.

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

Подведём итоги

Толпы религиозных фанатиков команды квалифицированных программистов часто отказываются от оператора GOTO, даже когда его использование целесообразно с точки зрения эффективности и наглядности программы.

Плохой тон в программировании? Если учитывать только «тон структурирования», то да. Но ведь ещё есть «тон быстродействия» и «тон компактности», поэтому нужно искать компромисс между ними. [6] Программисты «работающие в песочнице», как правило, решают задачи, в которых не приходится задумываться об экономии ресурсов, отсюда и вытекает недопонимание.

Игнорировать «тон структурирования» тоже нельзя, т.к. программу в любом случае придётся дорабатывать, и если в ней будет запутанная структура, то возникнут ненужные затраты. Как и в любых других практических решениях оптимальным является компромиссный вариант: использование GOTO разрешено, но со следующими оговорками:

1. Переходить можно только вперёд.
2. Заходить в блоки категорически нельзя (либо оставаться, либо выходить).

Благодарности

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

Кто же эти люди? Вот они:

Благодарю Дмитрия Леонова за создание сайта bugtraq.ru и за то, что ему удалось сплотить большое количество высококлассных специалистов на своём форуме. Именно на этом форуме развернулась самая интересная дискуссия. Благодарю людей, принявших участие в дискуссии на этом форуме:

Благодарю OlegY, Heller, Zef за примеры кода, где использование GOTO оправдано.

Благодарю HandleX за философские мысли о нужности GOTO при решении практических, а не теоретических задач.

Благодарю amirul за озвучивание правил применения GOTO.

Благодарю AMMOmium за мысль о «байках-страшилках» для начинающих программистов.

Благодарю команду программистов с форума codenet.ru за показательный пример классического спора, а именно следующих лиц: nilbog, koderAlex, OlgaKr, kerdan, kosfiz3A3-968M, IL84, fanto, Sanila_san, nixus, green, newonder.

PS. Спасибо за внимание. Буду рад комментариям; вопросы и возражения также приветствуются.

Библиография

1. Р. Лингер, Х. Миллс, Б. Уитт. Теория и практика структурного программирования. – М.: Мир, 1982.-406с.
2. Edsger W. Dijkstra.Go To Statement Considered Harmful // Communications of the ACM 11, March 1968. 147-148.
3. Niklaus Wirth. Good Ideas, through the Looking Glass // Computer, V. 39, No 1, January 2006.
4. Donald E. Knuth.Structured Programming with go to Statements // Computing Surveys, V.6, No.4. December 1974.
5. Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы.: Пер. с англ. – М.: Символ-Плюс, 2001.-304с.
6. Карев А.А.Код #кода.

• психология программирования
• философия программирования
• алгоритмы
• goto существует

Чем плох goto?

Вы хотели интересных тем? Так вот, я на днях думал, а почему goto так плох, и решил загуглить, почему же? Я нагуглил вот эту статью и, мне кажется, что goto можно использовать там, где это безопасно и нет возможностей выстрелить себе в голову ногу. Конечно, мы говорим о С++ и тут всегда есть такая возможность, но что уж тут. Так вот, используете ли Вы goto и почему, а если не используете, то опять же, почему?

P.S. Пожалуйста, давайте уважать друг друга и не писать ответы типа: «Потому что препод/форумчанин/в книге так сказали», давайте объективные причины писать! Спасибо.
(Жаль, что мне за такую «интересную» тему не заплатят )

94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

Чем плох управляемый С++?
Я дико извиняюсь за подобную тему. но дело в том, что мне сегодня задали этот вопрос и.

Чем плох uCoz?
Добрый день! Хотел бы услышать объективные мнения специалистов, на тему "Почему юКоз нельзя.

Чем плох make?
Дали написать реферат по make файлам и соответственно указать его минусы, а значит сравнить его с.

чем плох mysql_query
Просматривал вакансию на пхп juniora наткнулся на такое требование "В коде нет и намека на.

710 / 283 / 16
Регистрация: 31.03.2013
Сообщений: 1,340

Сообщение от GbaLog-

Вы хотели интересных тем?

— 2016 год
— «Чем плох goto»
— Интересная тема

Выбери любые два

Любитель чаепитий
3741 / 1798 / 565
Регистрация: 24.08.2014
Сообщений: 6,016
Записей в блоге: 1

Voivoid, А что, разве не интересная тема? Сколько проектов на том же github’e не смотрю, там нигде не было goto, ну, если только это был не С-проект. Почему его не используют? Очень полезный в некоторых случаях оператор.

710 / 283 / 16
Регистрация: 31.03.2013
Сообщений: 1,340

Сообщение от GbaLog-

Voivoid, А что, разве не интересная тема?

Она была интересная и актуальная лет так 50 назад.

Сообщение от GbaLog-

Почему его не используют?
Везде есть более декларативные средства (ну кроме как в C )
805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

Сообщение от GbaLog-

Почему его не используют?
его используют при программировании на языке ассемблера (вернее, его аналог — jmp)
26 / 26 / 11
Регистрация: 15.10.2013
Сообщений: 880

Сообщение от GbaLog-

А что, разве не интересная тема? Сколько проектов на том же github’e не смотрю, там нигде не было goto, ну, если только это был не С-проект. Почему его не используют? Очень полезный в некоторых случая оператор.

Наверное потому, что при использовании goto, программа становится (условно) нечитабельная.
Любитель чаепитий
3741 / 1798 / 565
Регистрация: 24.08.2014
Сообщений: 6,016
Записей в блоге: 1

Сообщение от Ferrari F1

его используют при программировании на языке ассемблера (вернее, его аналог — jmp)
Ну мы-то в ветке С++, поэтому, собственно, и вопрос по данному языку.

Сообщение от Voivoid

Везде есть более декларативные средства
Да, и какие же в С++?
26 / 26 / 11
Регистрация: 15.10.2013
Сообщений: 880

Сообщение от Ferrari F1

его используют при программировании на языке ассемблера (вернее, его аналог — jmp)
Наверное это goto аналог jmp =))
805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

Сообщение от GbaLog-

Ну мы-то в ветке С++, поэтому, собственно, и вопрос по данному языку.

Ну дак, в C++ можно же использовать ассемблерные вставки, следовательно, ассемблер — это С++
А вобще goto используется например для выхода из очень-очень глубоких вложенных циклов. Break’ом тут не обойдешься.

Любитель чаепитий
3741 / 1798 / 565
Регистрация: 24.08.2014
Сообщений: 6,016
Записей в блоге: 1

Сообщение от andreyananas

Наверное потому, что при использовании goto, программа становится (условно) нечитабельная.
Ну это всё зависит от степени «закостенелости» мозга под программирование без оного, ИМХО.
805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

andreyananas, по-твоему с++ появился раньше языка ассемблера, чтобы он мог наследовать из него что-то?

Любитель чаепитий
3741 / 1798 / 565
Регистрация: 24.08.2014
Сообщений: 6,016
Записей в блоге: 1

Сообщение от Ferrari F1

А вобще goto используется например для выхода из очень-очень глубоких вложенных циклов. Break’ом тут не обойдешься.

Ну об этом сказано в статье, что я скинул.
Вот и первый нормальный довод, почему можно использовать goto.

805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

Сообщение от GbaLog-

Ну об этом сказано в статье, что я скинул.

Я, как правило, темы и комментарии до себя никогда не читаю, прежде чем писать свой комментарий. Лень)

710 / 283 / 16
Регистрация: 31.03.2013
Сообщений: 1,340

Сообщение от GbaLog-

Да, и какие же в С++?

Зависит от задачи которая решается при помощи goto. Типичные пример: освобождение ресурсов в случае возникновения ошибки. В сишке используют для этого goto, в плюсах в goto необходимости нет, т.к. есть RAII.

805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

GbaLog-, в области структурного программирования есть теорема (https://ru.wikipedia.org/wiki/. _—_Якопини), согласно которой любую задачу можно решить, используя всего 3 управляющие структуры — последовательность, ветвление и цикл.
Оператор goto не вписывается в нормы структурного программирования, поскольку посредством него в программах происходит незакономерная передача управления из одного участка программы в другой (называется спагетти кодом)

26 / 26 / 11
Регистрация: 15.10.2013
Сообщений: 880

Сообщение от Ferrari F1

по-твоему с++ появился раньше языка ассемблера, чтобы он мог наследовать из него что-то?
Нет, я просто думал асм появился раньше *очень стыдно*
805 / 532 / 158
Регистрация: 27.01.2015
Сообщений: 3,017
Записей в блоге: 1

Сообщение от andreyananas

Нет, я просто думал асм появился раньше
Извини, я берега попутал, ты все верно написал)
2549 / 1208 / 358
Регистрация: 30.11.2013
Сообщений: 3,826

Сообщение от Ferrari F1

его используют при программировании на языке ассемблера (вернее, его аналог — jmp)
Да и в С++ используют его — switch case
2063 / 1542 / 168
Регистрация: 14.12.2014
Сообщений: 13,399

Сообщение от GbaLog-

а почему goto так плох

Единственное чем плох goto — плохой читабельностью программ где он повсеместно ЯВНО пользуется. НЕявно он присуствует во всех операторах ветвления и циклов, но это не мешает читабельности и восприятию алгоритма и хода выполнения. А огромное количество ошибок появляется именно от низкой читабельности инеправильного восприятия алгоритма и порядка исполнения. Этим собственно goto и плох при повсеместном использовании. Но к примеру выход сразу из пачки циклов по goto — единственное нормально читабельное решение вопроса. Хотя в современных реалиях и повсеместом ООП это пользуется редко. Гораздо чаще вместо goto за конец циклов встречается return который содержит его неявно.

Добавлено через 7 минут

Сообщение от GbaLog-

Почему его не используют?

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

IF A>B GOTO 20 ELSE GOTO 50

только так и никак иначе. тогда это действительно было очень неудобно. так это учебный язык. на боевом фортране все гораздо мрачнее. Т.е. и сыр-бор был поднят 50 лет назад по поводу того что такой goto зло, а удобнее вот так:

1 2 3 4 5

if (A>B){ //code }else{ // other code };

и типа обязать производителей компиляторов научить компиляторы транслировать такие конструкции в конструкции на машкоде с goto.

Почему goto зло?

И вот эта конструкция вполне допустима, но многие молодые программисты споткнутся и не ответят что вернет функция. Причина? неявный goto. Вы привели в пример код с 1 переходом. А если таких переходов 5-10 и они не последовательны. Т.е. один внутри другого, третий сбоку. Любую задачу, которая решается использованием goto можно реализовать циклами, суперпозицией и другими более простыми инструкциями. Вопрос — зачем использовать goto? Приведите пример, в котором код на goto выглядит проще и очевиднее чем циклы и прочее — используйте goto. В других случаях применение goto не оправдан и кроме недоумения, при анализе кода, не вызывает ничего.