Даже при правильном применении?

То есть, если пытаешься не использовать этот оператор и с помощью кучи флагов выйти из вложенных циклов, то программа работает столько же времени, что и с goto?

Но если с помощью goto изначально наделано меньше говнокода, чем без него, разве это не облегчает рефакторинг?

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

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

Здесь не понял. Вы на чем пишете? Я работаю с высокоуровневыми переменными, меняя их значения.

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

Но если с помощью goto изначально наделано больше говнокода, чем без него, разве это не усложняет рефакторинг? Интересная точка зрения, основанная на определении "говнокод".

В моих языках goto нет, попробовать не могу. Почему бы вам не проверить это и не написать результат? Я думаю, что разница будет несущественна.

будете ли вы настаивать на своём, если я вам приведу пример более лучшей читаемости чужой программы именно с оператором безусловного перехода?

То есть, если пытаешься
-----
Перформансе имеет смысл при сравнении равных алгоритмов.
При неравных - т.е при использовании GOTO - он бессмыслен.
разве это не облегчает рефакторинг?
-----
Опять - Нет.
Получается ручной анализ вместо автоматизированного.

Чушь. Алгоритм может быть одним и тем же, но по-разному реализован.

А разве автоматизированый анализ нельзя настроить на оператор перехода? Или религиозная парадигма не позволяет?

изменить кусок кода с "гото" практически невозможно
-----
??? - всегда есть возможность написать без него. Но иногда проще именно с ним.
и в любом бы случае все в одну процедуру бы не пихал
-----
А давай попробуем?
Дано - граф. Вершины - понятно. Дуги, или переходные функции - закрытое ДСП.
Есть гений-специалист в своей области, знающий как надо считать то, что надо
считать в частных случаях. Этот же спец ничего не понимает в программинге и
совершенно не заинтересован в раскрытии своей методики.
По тому, что надо делать, если делать в лоб, получается матрица, большего, чем
можно обработать на имеющейся технике, размера, да еще с инфинитным итератором.
Гений - знает когда можно срезать инфинитность и заменить ее чем-то относительно
простым - уровень отсечения - те самые 100 циклов, зависящих от данных в переходных
функциях т.е. не укладывающиеся с стандартные решения...
Ответ на вопрос - Почему так? - у гения, в закрытом ДСП...
Вы на чем пишете?
------
На всем, что способно описать алгоритм.
но неудобны для разбора чужой программы.
-----
Сие не есть правда.

Алгоритм может быть одним и тем же
-----
Угу... и граф переходов будет одним и тем же...
А разве автоматизированый анализ нельзя настроить на оператор перехода?
-----
Распознавание - можно. Чего-то большего мне пока не встречалось. Оно и
понятно - безусловный переход выпадает схемы, требующей приведения
системы к виду - один вход = один выход...
Или религиозная парадигма не позволяет?
-----
Она самая...

Исключения - это вариант возврата (return). Т.е. есть два способа откинуться: по честному (от звонка до звонка), и по исключению (досрочно-условно-по-амнистии). Раньше это моделировали вручную. Потом паттерн реализовали на синтаксическом уровне.
К goto исключения не имеют отношения. Разве что отдаленно в плане споров о степени их вредоносности. Исключения вполне структурны и усложняют логику программы только из-за введения дополнительных путей наверх. А goto использует свою систему координат (лейблы), которая никак не связана и может противоречить структурным координатам (названия процедур, циклы и т.п.)

Нифига. Return - это возврат к месту входа в подпрограмму. Исключение - это по сути longjmp.

Имеют. См. выше.

Исключения упрощают логику программы.

Ну конечно же нет А не боитесь, что во время дисскусии без разбора пример сразу будет назван говнокодом? Холивар все таки

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

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

Дело в том, что "прыжок к ближайшему обработчику исключений" как раз и следует пути возврата, т.е. мы идем обратно вдоль пути вызова процедур. Так что исключение это есть самый обычный возврат, плюс определенная логика его обработки, реализованная в языке (try-catch). То, что может происходить возрат "на много уровней выше" не меняет ситуацию, поскольку все эти уровни лежат на самом обычном пути возврата.

А при обычном возврате мы разве не бросаем все и не бежим к выходу? Так что исключения лучше называть "особенный возврат" или "специальный возврат", т.е. возврат, который можно обработать отдельно в точке возврата.
Вообще, часто нет принципиальной разницы как возвращаться: по обычному или по исключению, это вопрос хорошего дизайна. Простейший пример. Пишешь ты метод поиска чего-либо. Если ничего не найдено, то это обычный возврат или исключение? Однозначного ответа нет - делай как хочешь. В большинстве случаев проще с помощью обычного возврата, но некоторые озабоченные любят втыкать исключения куда не попадя (типа это круто), в результате вся программа это сплошные try-catch.
Так что исключения конечно бывает весьма полезны, но когда видишь, что люди с ней творят, то часто хочется, чтобы ее запретили.

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

Да, по стеку мы возвращаемся обратно. Но в пределах рутины нас выбрасывает куда-то.
Запускаем рутину. Из нее запускаем следующую и еще одну. Где то там в начале 5-го уровня обваливаемся. Нас выкинет на тот уровень, на котором естъ обработка исключения и в то место рутины, где эта обработка помещена. То есть обвалились мы на 5-м уровне в начале рутины, а выкинуло нас на 3-й, куда-то в середину.
В обычном варианте мы выходим через ту дверь, через которую вошли. Зашли в рутину - вышли на следующей строчке.

Есть. Все время вылазить по пожарной лестнице возможно, но как то не принято.

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

ППКС.

Ну кто назовёт говнокодом, пусть соизволит сказать как оно должно быть лучше, иначе он врун и мелкий засранец.
Нужно учитывать, что код пишет куча разных людей.
В теле функции могут в любой момент что-нибудь дополнить/убрать.
ссылка
Функция init_dev()
Особенно предлагаю задуматься, почему в функции всего лишь один return