Чи використовувати гото коли-небудь варто?

gotoмайже універсально не відлякує. Чи корисне використання цього твердження?

Про це кілька разів обговорювалося в Stack Overflow, і Кріс Гіллум підсумував можливі можливості використанняgoto :

Чіткий вихід із функції

Часто у функції ви можете виділяти ресурси та потребувати виходу в декілька місць. Програмісти можуть спростити свій код, поставивши код очищення ресурсу в кінці функції, всі "точки виходу" функції перейдуть на ярлик очищення. Таким чином, вам не доведеться писати код очищення в кожній "точці виходу" функції.

Вихід із вкладених циклів

Якщо ви знаходитесь у вкладеному циклі і вам потрібно вийти з усіх циклів, goto може зробити це набагато чистішим і простішим, ніж заяви про розрив та if-check.

Поліпшення продуктивності низького рівня

Це справедливо лише в перфрі-критичному коді, але оператори goto виконують дуже швидко і можуть дати вам імпульс під час переміщення через функцію. Однак, це меч з двома кінцями, оскільки компілятор, як правило, не може оптимізувати код, що містить gotos.

Я б зауважив, як багато хто стверджує, що у всіх цих випадках використання gotoвикористовується як засіб вийти з кута, зашифрованого самим собою, і, як правило, є симптомом коду, який може бути відновлений.

Конструкти потоків управління вищого рівня, як правило, відповідають поняттям в проблемній області. Рішення if / else - рішення, засноване на певній умові. Петля каже виконувати якусь дію повторно. Навіть заява про перерву говорить, що "ми це робили неодноразово, але зараз нам потрібно зупинитися".

З іншого боку, оператор goto, як правило, відповідає концепції в запущеній програмі, а не в проблемній області. Він говорить про продовження виконання у визначений момент програми . Хтось, хто читає код, повинен зробити висновок, що це означає щодо проблемної області.

Звичайно, всі конструкції вищого рівня можна визначити через готос та прості умовні гілки. Це не означає, що вони просто маскуються в готи. Подумайте про них як про обмежені готи - і саме обмеження роблять їх корисними. Заява перерви реалізується як перехід до кінця циклу, що вкладається, але краще думати про те, що він працює на циклі в цілому.

За інших рівних кодів, структура яких відображає структуру доменної області, як правило, легше читати та підтримувати.

Немає випадків, коли заява goto абсолютно необхідна (для цього є теорема ), але є випадки, коли це може бути найменш поганим рішенням. Ці випадки відрізняються від мови до мови, залежно від того, які конструкції вищого рівня підтримує мова.

Наприклад, у С я вважаю, що існує три основні сценарії, коли гото доречний.

1. Виривання з вкладеної петлі. Це було б непотрібно, якби мова мала мітку про перерву.
2. Виправлення розтягування коду (як правило, функціонального органу) у разі помилки чи іншої несподіваної події. Це було б зайвим, якби мова мала винятки.
3. Реалізація явної машини з кінцевим станом. У цьому випадку (і, я думаю, лише в цьому випадку) goto відповідає безпосередньо поняттю в проблемній області, переходячи з одного стану у вказаний інший стан, де поточний стан представлений тим, який блок коду виконується в даний час .

З іншого боку, явна машина кінцевого стану також може бути реалізована з оператором перемикання всередині циклу. Це має перевагу в тому, що кожен стан починається з одного і того ж місця в коді, що може бути корисним, наприклад, для налагодження.

Основне використання goto в досить сучасній мові (та, яка підтримує if / else та циклі) - це імітувати конструкцію керуючого потоку, якої немає у мові.

Звичайно, це залежить від мови програмування. Основна причина gotoсуперечливості полягає в тому, що її погані наслідки виникають, коли компілятор дозволяє занадто вільно використовувати її. Проблеми можуть виникнути, наприклад, якщо це дозволить вам використовувати gotoтаким чином, що тепер ви можете отримати доступ до неініціалізованої змінної або, що ще гірше, перейти до іншого методу і зіпсувати зі стеком викликів. Компілятор повинен нести відповідальність за те, щоб заборонити безглузді потоки управління.

Java намагалася "вирішити" цю проблему, gotoповністю відмовившись . Однак Java дозволяє використовувати returnвсередині finallyблоку і, таким чином, викликати випадкове проковтування винятку. Ця ж проблема все ще існує: компілятор не виконує своєї роботи. Видалення gotoз мови не виправило.

У C #, gotoє таким же безпечним , як break, continue, try/catch/finallyі return. Це не дозволяє використовувати неініціалізовані змінні, не дозволяє вистрибнути з остаточного блоку тощо. Компілятор поскаржиться. Це тому, що вона вирішує справжню проблему, яка, як я вже сказав, безглуздий контроль потоку. gotoне магічно скасовує аналіз визначеного призначення та інші розумні перевірки компілятора.

Так. Коли ваші петлі вкладені на кілька рівнів глибоко, gotoце єдиний спосіб елегантного прориву з внутрішньої петлі. Інший варіант - встановити прапор і вийти з кожного циклу, якщо цей прапор задовольняє умові. Це справді некрасиво і досить схильне до помилок. У цих випадках gotoпросто краще.

Звичайно, мітка Java, що робить мітку, breakробить те саме, але не дозволяє переходити до довільної точки коду, яка акуратно вирішує проблему, не дозволяючи тим, що приносять gotoшкоду.

Більша частина розчарувань надходить із свого роду "релігії", яка була створена навколо Бога Джикстра, що переконливо на початку 60-х років про те, що вона має беззаперечну владу:

• стрибати куди завгодно, в який би блок коду не був
  • функція не виконується з самого початку
  • петлі не виконуються з початку
  • пропущена ініціалізація змінної
• стрибати з будь-якого блоку коду без можливого очищення.

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

Зокрема, перша головна точка вище вже дозволена, а друга очищена (якщо ви gotoвийшли з блоку, стек розкручується належним чином і всі належні деструктори викликаються)

Ви можете посилатися на цю відповідь, щоб мати уявлення про те, як навіть код, не використовуючи goto, може бути нечитабельним. Проблема полягає не в тому, щоб перейти до себе, а в поганому використанні.

Я можу написати всю програму без використання if, просто for. Звичайно, він не буде добре читабельним, виглядає незграбним і зайво складним.

Але проблема не в цьому for. Це я.

Такі речі , як break, continue, throw, bool needed=true; while(needed) {...}і т.д., відзначаючи більш маскараду goto , щоб піти подалі від скімітаров цих Djikstrarian фанатиків, що -50 років після винаходу сучасного laguages- все ще хочуть , щоб їх укладений. Вони забули, про що говорив Джикстра, вони пам’ятають лише заголовок його записки (GOTO вважається шкідливим, і це навіть не було його назвою onw: це було змінено редактором), і звинувачувати і хитатися, бити і звинувачувати кожен контур, маючи ці 4 лист, розміщений в послідовності.

Настав 2011 рік: пора зрозуміти, що gotoзауваження, що стосується GOTOтвердження Джикстра, було переконливим.

Незвичайний сюди-сюди, доки він локальний для функції, рідко суттєво шкодить читабельності. Це часто приносить користь, звертаючи увагу на те, що в цьому коді відбувається щось незвичне, що вимагає використання дещо незвичної структури управління.

Якщо (локальні) готи значно завдають шкоди читабельності, то зазвичай це знак того, що функція, що містить goto, стала надто складною.

Останнім гото, який я вклав у фрагмент коду С, було створення пари перемикаючих петель. Це не вписується у звичайне визначення "прийнятного" використання goto, але функція в результаті вийшла значно меншою та зрозумілішою. Щоб уникнути гото, потрібно було б особливо безладно порушити DRY.

Я думаю, що вся ця проблема була випадком гавкання неправильного дерева.

GOTO як такий не здається мені проблематичним, але, швидше, це дуже часто симптом фактичного гріха: код спагетті.

Якщо GOTO спричиняє велике перетинання ліній контролю потоку, то це погано, період. Якщо він не перетинає жодних ліній контролю потоку, це нешкідливо. У сірій зоні між нами є такі речі, як виправлення циклу, все ще є деякі мови, які не додали конструкцій, які б охоплювали всі законно-сірі випадки.

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

Так, goto може використовуватися для використання досвіду розробника: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

Однак так само, як і будь-який потужний інструмент (покажчики, багаторазове успадкування тощо), його потрібно дисциплінувати, використовуючи його. У прикладі, наведеному у посиланні, використовується PHP, який обмежує використання конструкції goto на тій самій функції / методі та відключає можливість перейти в новий блок управління (наприклад, цикл, оператор переключення тощо).

Залежить від мови. Наприклад, він все ще широко використовується в програмуванні Cobol. Я також працював над пристроєм Barionet 50, мова програмування якого є раннім діалектом BASIC, що, звичайно, вимагає використання Goto.

Я б сказав, що ні. Якщо ви виявите потребу в використанні GOTO, я буду обділятися, що потрібно змінити код.

gotoможе бути корисним при перенесенні застарілого коду асемблера до C. У першому випадку перетворення інструкції за інструкцією на C, використовуючи gotoяк заміну інструкції асемблера branch, може забезпечити дуже швидке перенесення.

Я б заперечив "ні". Їх завжди слід замінити на інструмент, більш конкретний для проблеми, з якою використовується гото (якщо це не доступно на вашій мові). Наприклад, заяви про перерви та винятки вирішують раніше вирішені goto проблеми усунення циклу та обробку помилок.