Ваше отношение к goto

Всем привет.

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

Парочка примеров, с которыми я столкнулся буквально вот на днях:

Какие выходы, не используя goto:
1. Либо сделать присвоение predicate = null(или ещё что) и избавиться от блока default целиком. Хотя лично мне спокойнее, когда default в коде имеется.
2. В блоке default скопипастить кейс, на который ссылаюсь(тогда при изменениях надо помнить, что менять нужно в 2 местах).

В свитче я оставил goto(мой первый goto в жизни)

Другой пример:

Какие выходы, не используя goto:
1. Применить SelectMany к groups и оставить один цикл foreach.
2. Повозиться с флагами и break'ами.

Здесь мне готушить не хочется, не знаю почему.

Т.е. можно и без goto жить в обоих приведенных(и ещё n неприведённых) примерах.

0

Сообщение от escoult Обратите внимание, во всей теме, нет ни одной четко обозначенной причины, почему в таком то куске исходника используется оператор goto.

Я уже давал ранее ссылку.
Даю оттуда пост с кодом:

Сообщение от Элд Хасп Пример для одной переменой C# 17 18 19 20 21 22 23 24 25             // double a, b, c; УБРАТЬ !!!         inputA:             Console.WriteLine("Введите значение a");             if (!double.TryParse(Console.ReadLine(), out double a))             {                 Console.WriteLine("Ошибка ввода!!! Повторите ввод !!!");                 goto inputA;              }

И обоснование его применения:

Сообщение от Элд Хасп Теперь к конкретно моему примеру. goto и метка расположены в пределах 5 строк. Общий код охватывается одним взглядом. Код структурирован и выполняет одну функцию. Все вместе: легко читаемый, прозрачный код. Каким либо образом goto ухудшает его качество? Однозначно - нет. Теперь рассмотрим вариант с циклом от QuakerRUS. Код структурирован, легкочитаем, прозрачен - значит качественный. Но давайте сравним его с пользовательской стороны. Первый цикл одинаков для обоих примеров. А вот во втором появляются различия. В моё примере выводится фраза "Введите значение a", во втором - этой фразы нет. Следовательно выбор в пользу того или иного кода определяется не его кодом (они оба качественные), а требованиями пользовательского интерфейса. Если же реализовывать такой подход как в моём примере, то сделать качественный простой код без goto, наверное, не выйдет. Придётся вводить или дублирование кода, или вечный цикл и дополнительные проверки - и то и другое ухудшает качество кода.

Добавлено через 2 минуты
В той же теме есть реализация с использованием метода, но она лучше в сравнении с goto только для случая неоднократного применения этого метода.
Допустим, для ввода нескольких переменных.
Если использование метода будет однократным, то такая реализация хуже чем использование goto.

0

Сообщение от Элд Хасп Я уже давал ранее ссылку. Даю оттуда пост с кодом:

Я говорил об исходниках .NET.

0

Сообщение от escoult Я говорил об исходниках .NET.

Неверно понял.

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

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

В таких обстоятельствах, я априори считаю коды исходников "шаблоном (или примером) правильного кода".
Сомневаться в верности принятия решения по определённой реализации у меня нет.

0

Сообщение от Элд Хасп Теперь рассмотрим вариант с циклом от QuakerRUS.

Элд Хасп, раз уж меня упомянули... То в той теме далее приведены варианты без goto, которые мне нравятся больше. И мое обоснование, почему мне не нравится этот вариант постом ниже, не буду копировать.

Мой вариант.

И чуть более универсальный вариант от Rius, который мне понравился:

0

Сообщение от Элд Хасп В таких обстоятельствах, я априори считаю коды исходников "шаблоном (или примером) правильного кода".

Вопрос не в правильности, а в обоснованности применения оператора. Разработчик .NET возможно сможет назвать конкретные причины, почему он использует goto. Вы применяете, потому что видели, что так делают разработчики, но почему они так сделали не знаете. Огромная разница.

0

Сообщение от Элд Хасп В таких обстоятельствах, я априори считаю коды исходников "шаблоном (или примером) правильного кода". Сомневаться в верности принятия решения по определённой реализации у меня нет.

Элд Хасп, а вот это уже настоящая религия .

0

Сообщение от wizard41 а вот это уже настоящая религия

Доверять тем кто однозначно более опытен и квалифицирован чем я?
Может мне и вместо докторов только самолечением заниматься?

Сообщение от escoult Вопрос не в правильности, а в обоснованности применения оператора.

Сообщение от escoult Вы применяете, потому что видели, что так делают разработчики, но почему они так сделали не знаете

С чего вы сделали такие выводы?
Из того что его применяют разработчики .Net я делаю только вывод о том, что в определённых ситуациях, задачах его можно использовать.
И если мне попадётся такая задача, где я посчитаю (в меру моего опыта и квалификации), что использование goto это лучший вариант реализации, то я не буду от него отказываться, только из-за того что у кого-то "может вызвать рвотный рефлекс".

Сообщение от QuakerRUS Мой вариант.

Он не в полной мере выполняет условия задачи, о чём я уже писал.
Если изменять условия задачи, то конечно нет смысла для изменённых условий использовать goto.

Сообщение от QuakerRUS чуть более универсальный вариант от Rius

Этот выполняет, но по мне, вечный цикл с прерыванием по условию - это хуже чем goto.

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

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

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

Сообщение от QuakerRUS Элд Хасп, раз уж меня упомянули...

Со всем уважением, я не специально.
Копировал пост и не стал его редактировать.

0

Сообщение от Элд Хасп Этот выполняет, но по мне, вечный цикл с прерыванием по условию - это хуже чем goto.

У меня противоположное мнение. Без goto в том примере нет нагромождения кода или повторяющегося кода. Он такой же прозрачный и при этом не нарушает структурность кода.

Сообщение от Элд Хасп Как писал kolorotur,иногда приходится выбирать не между плохо и хорошо, а между плохо и ещё хуже.

Да, но также он писал:

Сообщение от kolorotur > Когда Вы в последний раз прибегали к использованию goto? В продакшене — никогда, ибо не было нужды.

О чем это говорит? Полагаю о том, что я писал ранее в той теме:

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

Сообщение от Элд Хасп Попробуйте описать на ваш взгляд критерии оценки качества кода, которые можно применить независимо от используемых инструкций. Исключить goto у вас получится только если явно вписать "goto - это плохо без всяких аргументов".

На эту тему могу лишь привести ссылку из той же темы от Rius:
https://www.cyberforum.ru/blog... g5841.html

Разумеется все написанное - мое ИМХО. На истину в первой инстанции не претендую.

0

Сообщение от QuakerRUS На эту тему могу лишь привести ссылку из той же темы от Rius: https://www.cyberforum.ru/blog... g5841.html

Цитата из Вики:

Несколько исследований ставят под вопрос эффективность правил MISRA.[11] В частности, выявлялась негативная корреляция между нарушениями правил MISRA и наблюдаемыми сбоями программ.[12]

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

Сообщение от QuakerRUS Да, но также он писал:

Я об это тоже писал несколько раз.
Мне и kolorotur на практике не встречались задачи где была бы в нём необходимость.
Но наш практический опыт нисколько не означает, что goto НЕЛЬЗЯ применять в принципе.

Сообщение от QuakerRUS У меня противоположное мнение.

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

0

Сообщение от Элд Хасп Но наш практический опыт нисколько не означает, что goto НЕЛЬЗЯ применять в принципе.

А я и не говорил, что нельзя. В опросе я выбирал вариант "Использую, если имеет смысл". Но это не значит, что его стоит использовать там, где этого можно избежать. Мне тоже еще ни разу не понадобилось его использовать.

Сообщение от Элд Хасп Несколько исследований ставят под вопрос эффективность правил MISRA.[11] В частности, выявлялась негативная корреляция между нарушениями правил MISRA и наблюдаемыми сбоями программ.[12]

Сообщение от Элд Хасп Я очень коротко обозначил принципы оценки качества кода. Сделайте то же самое без ссылок на MISRA, поскольку там запрет на goto не носит абсолютного характера и нисколько не противоречит моему взгляду на него.

Могу лишь развести руками. Не знаю на счет эффективности MISRA, но я разделяю их точку зрения. Особенно это касается пунктов 15.1, 15.2 и 15.3 (правда пункт 15.3 для C# не актуален), так как они помогают соблюсти структурность программы. Перефразирую их своими словами, раз уж вы просите "без ссылок":

1. goto не стоит использовать, если этого можно избежать без нагромождения дополнительного кода, уменьшения прозрачности кода, использования повторяемого кода, значительного понижения эффективности кода в узких местах, так как он понижает структурность программы и повышает сложность чтения кода.
2. goto назад повышает сложность чтения кода больше чем goto вперед, так как код читается сверху вниз.
3. goto стоит использовать только в текущий блок или в один из блоков наружу. Для C# не актуально, так как только так и можно использовать в нем goto. При этом goto наружу можно избежать, вынеся эти блоки в отдельный метод.

На правах ИМХО.

0

Сообщение от QuakerRUS Перефразирую их своими словами, раз уж вы просите "без ссылок":

Я просил немного о другом.
Сформулировать требования к качественному коду без относительно используемых операторов.
И потом проверить насколько использование goto нарушает эти требования.
Вы же, по сути, привели не критерии оценки качества кода, а "goto - это плохо".

Хотя даже в этих пунктах (впрочем как и в MISRA) не "запрет goto", а рекомендации по незлоупотреблению им.
С этим я согласен.
Действительно разумное его использование на практике встречается крайне редко.
Мне пока не встречалось.
За исключением маленькой учебной задаче с которой началась наша предыдущая тема.

Сообщение от QuakerRUS goto стоит использовать только в текущий блок или в один из блоков наружу. Для C# не актуально,

Я думаю, в данном пункте в отношении Шарпа, надо подразумевать учёт вложенности блоков.
Когда происходит переход в одноуровневый или нижележащий блок.
Типа из одного else if {} в другой else if {}.
Переход же из вложенного блока во внешний допустим, так как действительно в Шарпе по иному goto использовать невозможно.

Добавлено через 4 минуты
QuakerRUS, у меня нет текста MISRA.
Но было бы интересно, что там написано в отношении вечных циклов....

0

Сообщение от Элд Хасп Сформулировать требования к качественному коду без относительно используемых операторов.

При написании кода следует придерживаться следующих принципов (может что-то пропустил, не обессудьте):

• Писать код прозрачно / не усложнять код, т.е. разбивать блоки на части, избегать избыточных переменных и магических чисел, конструкций, усложняющих восприятие кода при его чтении;
• Не повторять код, т.е. не писать дважды то, что можно написать один раз, не изобретать велосипеды.
• Писать код структурно, т.е. выстраивать логику из последовательных блоков.
• Оформлять код, т.е. визуально грамотно писать код, использовать корректные отступы.

Можно придумать еще разные рекомендации касательно оптимальности, кроссплатформенности и т.п. при желании.

Сообщение от Элд Хасп И потом проверить насколько использование goto нарушает эти требования.

В примере из той темы нарушается первый и третий пункт, которые я описал.

Сообщение от Элд Хасп Вы же, по сути, привели не критерии оценки качества кода, а "goto - это плохо".

Главное, что я при этом написал свое обоснование, почему в конкретном случае я считаю, что "goto - это плохо".

Сообщение от Элд Хасп За исключением маленькой учебной задаче с которой началась наша предыдущая тема.

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

Сообщение от Элд Хасп Я думаю, в данном пункте в отношении Шарпа, надо подразумевать учёт вложенности блоков. Когда происходит переход в одноуровневый или нижележащий блок. Типа из одного else if {} в другой else if {}.

Может я вас не понял, но из одного else if {} вроде как нельзя перейти в другой else if {}.

Сообщение от Элд Хасп QuakerRUS, у меня нет текста MISRA. Но было бы интересно, что там написано в отношении вечных циклов....

Я тоже его не читал, кроме вырезок из той темы. На мой взгляд (и я уже писал об этом раньше) ничего плохого в вечных циклах нет. Это стандартная практика в структурном программировании.

0

Элд Хасп,
создается впечатление, что вы пытаетесь что-то доказать/опровергнуть, хотя в целом, ваша позиция относительно goto уже давно ясна. Более того, она фактически совпадает с мнением высказавшихся тут.
Как вы совершенно точно отметили где-то выше (не буду искать для цитаты, примерно сказано было так: "современные ЯП ориентированы прежде всего на одновременную работу нескольких программистов"), то в этом случае про goto лучше забыть, т.к. далеко не все относятся к нему с такой же лояльностью, ну как мы, что ли.
Для "собственного употребления" - да хоть на каждой второй строке.

0

Сообщение от Элд Хасп С чего вы сделали такие выводы?

С того, что другой причины вы не назвали. Или вы можете назвать причины, по которым разработчики .NET используют оператор goto?

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

Понимаете разницу с "религией"? То есть оператор goto обоснован там где невозможно достичь такой же эффективности без применения этого оператора. В вашем коде (я имею ввиду ваш пример), в качестве обоснования вы приводите только ваши собственные критерии оценки качества.

Интересно, что в доках microsoft, оператор вполне законный, и применяется как раз в описанных в теме случаях, switch и nested loops. Нет ни слова, ни даже намека на то что оператор является устаревшим, нет рекомендаций воздерживаться от использования. При этом у самих microsoft этот оператор можно встретить, пожалуй лишь в исходниках.

Справедливости ради, надо заметить, что в switch он выглядит вполне себе нормально и читабельность особо не ухудшает, поскольку находится внутри одного блока с метками. Тем не менее, отсутствие языковой гарантии перехода лишь по меткам case, ставит и этот случай в один ряд с остальными.

2

Сообщение от QuakerRUS В которой он совершенно не нужен, и был приведен код (в том числе вами), реализующий то же самое, но без уменьшения структурности и прозрачности.

Да, и там же я объяснил в каких случаях лучше использовать goto, а в каких дополнительный метод.
Создавать метод ради разового применения, только с целью избавиться от goto - это намеренное усложнение и, следовательно, ухудшение качества кода.

Сообщение от QuakerRUS В примере из той темы нарушается первый и третий пункт, которые я описал.

Я не вижу чем применение goto в том примере нарушает первый пункт.
Только разве его органическим неприятием.
Но это субъективный фактор вкуса.

По третьему пункту, зависит от определения, что такое "структурно" и "последовательные блоки".
Однозначно под этим не понимается строго последовательное выполнение кода.
Иначе под это ограничение попали все циклы.

Поэтому объясните почему блок с циклом - это структурно, блок с меткой и goto - это не структурно?

Сообщение от QuakerRUS Может я вас не понял, но из одного else if {} вроде как нельзя перейти в другой else if {}.

Я поэтому и написал "типа".
В Шарпе нельзя. Но может можно в каких-то иных языках - я не знаю.
В Шарпе есть видимость с нижнего уровня на верхний.
Я просто не понял вашего

Сообщение от QuakerRUS Для C# не актуально, так как только так и можно использовать в нем goto

Пытался как-то "догнать смысл".
С моей точки зрения, этот пункт не то что бессмыслен для Шарпа, а он учитывается в нём на уровне синтаксиса, спека.

Сообщение от QuakerRUS На мой взгляд (и я уже писал об этом раньше) ничего плохого в вечных циклах нет.

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

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

Сообщение от wizard41 Для "собственного употребления" - да хоть на каждой второй строке.

Ну, да - и .Net отличный пример кода для собственного употребления....

Сообщение от wizard41 создается впечатление, что вы пытаетесь что-то доказать/опровергнуть, хотя в целом, ваша позиция относительно goto уже давно ясна.

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

Об этом и спор.

Сообщение от escoult Или вы можете назвать причины, по которым разработчики .NET используют оператор goto?

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

Сообщение от escoult Но проблема goto появилась из других соображений

Она появилась в период перехода от старых процедурных ЯП к новым (в первую очередь ООП ЯП).
Я это прекрасно помню, и помню насколько часто его раньше использовали.
Тот же HF тоже совершал такой переход.
Но одно дело необоснованно частое его применение, которое идёт во вред качеству кода.
И полный запрет на его применение даже в тех случаях когда он может сделать код качественнее.

Из первого никак не вытекает второго.

Сообщение от escoult В вашем коде (я имею ввиду ваш пример), в качестве обоснования вы приводите только ваши собственные критерии оценки качества.

Естественно, а чьи мне приводить?
В той же выписке из MISRA на которую сослались ранее, по сути, сказано тоже самое: Не использовать, если может ухудшить.

Я, кроме различных холиваров, нигде не видел объективной оценки кода в коnором использование goto ВСЕГДА ухудшает качество кода.
Только если в этих критериях жёстко задано "Goто = плохо!", без всякого объективного обоснования.

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

Сообщение от escoult что в доках microsoft, оператор вполне законный

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

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

0

Сообщение от Элд Хасп Да, и там же я объяснил в каких случаях лучше использовать goto, а в каких дополнительный метод. Создавать метод ради разового применения, только с целью избавиться от goto - это намеренное усложнение и, следовательно, ухудшение качества кода.

Вариантов там на любой вкус. Не нравится с методом - берем вариант от Rius.

Сообщение от Элд Хасп Я не вижу чем применение goto в том примере нарушает первый пункт. Только разве его органическим неприятием. Но это субъективный фактор вкуса.

Усложнение восприятия кода при его чтении, так как придется искать эту метку. И хорошо (нет), если она была тремя строками ранее, а не тридцатью тремя после обрастания проекта новыми фичами.

Сообщение от Элд Хасп По третьему пункту, зависит от определения, что такое "структурно" и "последовательные блоки". Однозначно под этим не понимается строго последовательное выполнение кода. Иначе под это ограничение попали все циклы. Поэтому объясните почему блок с циклом - это структурно, блок с меткой и goto - это не структурно?

К структурам относятся конструкции ветвления (if, if..else, switch) и повторения (while, do..while, for, foreach). То есть блок с циклом - это структура и это нормально для соблюдения принципа структурного программирования. А переход по метке нарушает принцип структурного программирования. Весь смысл структурного программирования и сводится по сути к избавлению от низкоуровневых переходов в пользу высокоуровневых конструкций. О причинах хорошо расписал выше escoult.

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

Он подтверждается тем, что не противоречит принципу структурного программирования и не противоречит остальным приведенным пунктам.

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

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

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

Сообщение от Элд Хасп В Шарпе нельзя. Но может можно в каких-то иных языках - я не знаю.

В C/C++ можно.

0

Сообщение от QuakerRUS И хорошо (нет), если она была тремя строками ранее, а не тридцатью тремя после обрастания проекта новыми фичами

За это я писал.
goto и метка должны быть в пределах "одного взгляда" - максимум 10-15 строк.
Вообще методы размером больше пары страниц кода (грубо полсотни-сотни) строк - уже значительно ухудшают понимание кода.
goto и метка - это единый блок кода внутри метода (просто он не выделен явно, но можно и выделить при желании) и как любой блок нежелательно делать его размером больше чем можно сразу охватить взглядом.

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

Сообщение от QuakerRUS А переход по метке нарушает принцип структурного программирования.

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

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

Сообщение от QuakerRUS Он подтверждается тем...

Цитату можете дать?
Если нет, то не надо на него вообще ссылаться.
Даже та выписка которая предоставлена, и то ничего про "запрет goto" не содержит.

В результате мы опять скатываемся ко всем холиварам на эту тему.
Вы думаете так - я думаю иначе.

Сообщение от QuakerRUS По мне потенциальная опасность для багов и прочего, а также сложность отладки, обратно пропорциональны прозрачности кода

Согласен.
И вечный циклы очень негативно на это влияют, на мой взгляд.

0

Сообщение от Элд Хасп goto и метка должны быть в пределах "одного взгляда" - максимум 10-15 строк.

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

Сообщение от Элд Хасп А чем goto+метка не блок?

Элд Хасп, почитайте что-нибудь из теории структурного программирования. Да хоть в той же Википедии можно почитать, вроде неплохо написано.
https://ru.wikipedia.org/wiki/... 0%B8%D0%B5

Вы пробовали читать исходники на Ассемблере? Там goto на каждом шагу и расположены не так далеко друг от друга. Однако код этот прочесть не так уж просто, так как не следует принципам структурного программирования.

Сообщение от Элд Хасп Цитату можете дать?

По-моему это настолько очевидно, что никто не заморачивается тем, что надо давать пояснения для использования вечного цикла (чем он хуже обычного?), так как конструкция while (true) на мой взгляд более чем прозрачная.

Сообщение от Элд Хасп Вы думаете так - я думаю иначе.

Поэтому я почти под каждым сообщением написал "ИМХО". Никого переубеждать я не планировал.

Сообщение от Элд Хасп И вечный циклы очень негативно на это влияют, на мой взгляд.

Не вижу негативности. Условие выхода из цикла четко прописано перед break.

1

Сообщение от Элд Хасп Ну, да - и .Net отличный пример кода для собственного употребления....

Мы пишем в Net, для Net из под Net. От сюда вытекает, что функции, используемые нами в Net для Net должны работать несколько быстрее чем то, что мы пишем в Net. Логично? По моему да. Однако ни нам ни вам не известно почему в исходниках Net применили goto. Вы продолжаете верить в "профессионалов Net" как в бога. (религия?)

Сообщение от Элд Хасп Но кто-то делает из этого вывод, что его использование категорически негативно и плоха.

Да практически все. Основная масса работодателей, сеньоров, тимлидов. Я же говорил вам ранее - это дань традициям. Этого не избежать.

Сообщение от Элд Хасп Я же с таким выводом не согласен.

Ваше право. Так что вы тут доказываете тогда? (де-жа-вю).

0

Если интересны мои оправдания , то я ещё раз беспристрастно проанализировал - почему или зачем я использовал goto в своём проекте на Vb.Net. Обобщённый вывод такой:
Весь код лежал в одной плоскости. Goto давал мне идеальную возможность не выходить за этот уровень. Это реализация без использования излишней логики или абстракций.

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

- парсер. есть сложная (на тот момент или непродуманный сценарий) логика анализа строк файла.
Например, я обнаружил в строке "флаг" нужных данных, но эти данные зависят от следующих. Поэтому я читаю следующую строку... а эту "держу в уме". И тут возникает сложная ситуация - если там найдены предсказуемые данные, то я просто сохраняю результат и перехожу к новому циклу. А если нет то, там может быть снова строка с "флагом". И мне волей не волей приходится бросить "goto" чтобы снова вызвать обработу этой новой строки. Иначе если я бы ушёл на новый глобальный цикл чтения что потерял бы уже прочтённую строку.
Конечно моя ошибка - в цикле должна быть только одна строка чтения данных из файла. Но тогда мне надо иметь флаги состояний определяющие что я читал последний раз, были ли это ожидаемые данные, завершилось ли это успешно... Лексер парсер не иначе. Но мне было быстро, просто и понятно - вызвать блок анализа строки.

Надеюсь поток мыслей был полезен.

1