Rifat писал(а):
Формулировка была не совсем точна, пусть нельзя прыгнуть в любую точку, но можно прыгнуть в начало ЛЮБОЙ ветки.
Рифат, Вы частично правы.
Вы полностью правы в том, что можно прыгнуть в начало ЛЮБОЙ ветки. Впрочем, нет. Не любой ветки, а только ветки данного силуэта. Адрес не может указывать на ветку ДРУГОГО силуэта.
Почему ВЫ частично правы? Потому что goto имеет два недостатка:
1. goto может осуществить переход в ЛЮБОЕ место.
2. goto можно вставить в ЛЮБОЕ место;
Рифат, Вы не упомянули о том, что икону "Адрес" ДРАКОНа нельзя вставить в ЛЮБОЕ место (и в этом второе отличие от goto).
Но это не все мои аргументы. Иконы "Имя ветки" и "Адрес" находятся на самом виду. Они под неусыпным контролем.
Они обозначают наиболее важные Смысловые части алгоритма. Они имеют смысловые имена. Вероятность ошибки при переходе от Адреса к началу ветки ничтожно мала.
Дракон существенно отличается от текстовых языков с goto
Вспомним стандартные претензии к goto.
Цитата:
Начиная с 1970-х годов оператор безусловного перехода goto оказался в центре систематической и всевозрастающей критики. Неправильное и необдуманное использование оператора goto в исходном тексте программы приводит к получению запутанного, неудобочитаемого «спагетти-кода». По тексту такого кода практически невозможно понять порядок исполнения и взаимозависимость фрагментов.
Впервые эта точка зрения была отражена в статье Эдсгера Дейкстры «Оператор Go To считается вредным»[9][3]. Дейкстра заметил, что качество программного кода обратно пропорционально количеству операторов goto в нём. Статья приобрела широкую известность, в результате чего взгляды на использование оператора goto были существенно пересмотрены.
В работе «Заметки по структурному программированию»[10] Дейкстра обосновал тот факт, что для кода без goto намного легче проверить формальную корректность.
Код с goto трудно форматировать, так как он может нарушать иерархичность выполнения (парадигму структурного программирования) и потому отступы, призванные отображать структуру программы, не всегда могут быть выставлены правильно. Кроме того, оператор goto мешает оптимизации компиляторами управляющих структур[11].
Некоторые способы применения goto могут создавать проблемы с логикой исполнения программы:
Если некоторая переменная инициализируется (получает значение) в одном месте и потом используется далее, то переход в точку после инициализации, но до использования, приведёт к тому, что будет выбрано значение, которое находилось в памяти, выделенной под переменную, до момента выделения (и которое, как правило, является произвольным и случайным).
Передача управления внутрь тела цикла приводит к пропуску кода инициализации цикла или первоначальной проверки условия.
Аналогично, передача управления внутрь процедуры или функции приводит к пропуску её начальной части, в которой производится инициализация (выделение памяти под локальные переменные).
Доводы против оператора goto оказались столь серьёзными, что в структурном программировании его стали рассматривать как крайне нежелательный.
Это нашло отражение при проектировании новых языков программирования. Например, goto запрещён в Java и Ruby. В ряде современных языков он всё же оставлен из соображений эффективности в тех редких случаях, когда применение goto оправданно. Так, goto сохранился в Аде — одном из наиболее продуманных с точки зрения архитектуры языков за всю историю[12].
Однако в языках высокого уровня, где этот оператор сохранился, на его использование, как правило, накладываются жёсткие ограничения, препятствующие использованию наиболее опасных методов его применения: например, запрещается передавать управление извне цикла, процедуры или функции внутрь. Стандарт языка C++ запрещает обход инициализации переменной с помощью goto
Цитата:
Структурное программирование призвано, в частности, устранить беспорядок и ошибки в программах, вызванные трудностями чтения кода, несистематизированным, неудобным для восприятия и анализа исходным текстом программы. Такой текст нередко характеризуют как «спагетти-код».
Спагетти-код (spaghetti code) — плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, содержащая много операторов goto (особенно переходов назад), исключений и других конструкций, ухудшающих структурированность[8]. Самый распространённый антипаттерн программирования.
Спагетти-код назван так потому, что ход выполнения программы похож на миску спагетти, то есть извилистый и запутанный. Иногда называется «кенгуру-код» (kangaroo code) из-за множества инструкций jump.
В настоящее время термин применяется не только к случаям злоупотребления goto, но и к любому «многосвязному» коду, в котором один и тот же небольшой фрагмент исполняется в большом количестве различных ситуаций и выполняет много различных логических функций[8].
Спагетти-код может быть отлажен и работать правильно и с высокой производительностью, но он крайне сложен в сопровождении и развитии[8]. Доработка спагетти-кода для добавления новой функциональности иногда несет значительный потенциал внесения новых ошибок. По этой причине становится практически неизбежным рефакторинг (code refactoring) — главное лекарство от спагетти.
Вся эта аргументация о вреде goto справедлива.
Но эта аргументация не имеет никакого отношения в Дракону.
Аргументы против goto никак не компрометируют Дракон.
Они про совсем другие недостатки.
Рифат, разве не так?