Библиотека knigago >> Компьютеры: Разработка ПО >> Программирование: прочее >> Доводы против оператора goto


СЛУЧАЙНЫЙ КОММЕНТАРИЙ

# 2137, книга: Тьма близко
автор: Виктор Ночкин

Виктор Ночкин Фэнтези: прочее "Тьма близко" - захватывающий роман в жанре фэнтези, исследующий борьбу добра и зла в мрачном и таинственном мире. История разворачивается в королевстве Антария, где древнее пророчество предупреждает о надвигающейся тьме. Король отправляет своих лучших рыцарей в опасное путешествие, чтобы найти артефакт, способный отразить надвигающуюся угрозу. Главный герой, Эрик, является молодым и отважным рыцарем, который присоединяется к экспедиции. По пути он...

Эдсгер Вайб Дейкстра - Доводы против оператора goto

Доводы против оператора goto
Книга - Доводы против оператора goto.  Эдсгер Вайб Дейкстра  - прочитать полностью в библиотеке КнигаГо
Название:
Доводы против оператора goto
Эдсгер Вайб Дейкстра

Жанр:

Статьи и рефераты, Самиздат, сетевая литература, Литература ХX века (эпоха Социальных революций), Программирование: прочее

Изадано в серии:

неизвестно

Издательство:

Интернет-издательство «Stribog»

Год издания:

ISBN:

неизвестно

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "Доводы против оператора goto"

За многие годы я утвердился во мнении о том, что квалификация программистов — функция, обратно зависящая от частоты появления операторов go to в их программах. Позже я открыл, почему оператор go to производит такой пагубный эффект, и я убежден в том, что оператор go to должен быть отменен в языках программирования «высокого уровня» (т. е. отовсюду, кроме, возможно, простого машинного кода). В то время я не счел это открытие слишком важным. Теперь же я отправляю свои соображения для публикации, потому что меня подтолкнула к этому развернувшаяся сейчас дискуссия на эту тему.

Читаем онлайн "Доводы против оператора goto". [Страница - 2]

стр.
восприятия процессов, порождаемых предложениями повторения. С введением предложений повторения текстуальных индексов уже недостаточно для описания динамического состояния процесса. С каждым входом в предложения повторения, однако, мы можем связать, так называемый, «динамический» индекс, исправно подсчитывающий порядковый номер текущего повторения. Если предложения повторения (также как вызовы процедур) могут применяться с вложением, мы находим, что теперь развитие процесса может быть однозначно охарактеризовано последовательностью (смешанной) текстуальных и/или динамических индексов.

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

Почему нам нужны эти независимые координаты? Причина в том — и это представляется неотъемлемым для последовательных процессов — что мы можем интерпретировать значение переменной только с учетом состояния процесса. Если мы хотим подсчитать число n, скажем, людей в комнате, изначально пустой, мы можем достичь этого путем увеличения n на единицу всякий раз, когда мы видим, что кто-то вошел в комнату. В промежуточный момент, когда мы увидели кого-то входящего в комнату, но еще не выполнили последующего увеличения n, его значение равно числу людей в комнате минус один!

Разнузданное применение оператора go to имеет прямым следствием то, что становится ужасно трудно найти осмысленный набор координат, в которых описывается состояние процесса. Обычно люди принимают во внимание также и значения некоторых избранных переменных, но это не вопрос, потому что состояния процесса зависит, как понимать эти значения! С оператором go to можно, конечно, все еще описывать состояние процесса однозначно при помощи счетчика числа действий, выполненных от старта программы (т. е., некоторой разновидности нормализованных часов). Трудность в том, что такие координаты, хотя они и уникальные, просто бесполезные. С такими координатами система становится чрезвычайно сложной, сталкиваясь с необходимостью определения всех тех точек состояния, в которых, скажем, n равно числу людей в комнате минус один!

Оператор go to сам по себе просто слишком примитивен; он создает слишком сильное побуждение внести путаницу в программу. Рассмотренные предложения могут оцениваться и приветствоваться как сдерживающие его применение. Я не заявляю, что упомянутые предложения являются исчерпывающими в том смысле, что они удовлетворяют любым требованиям, но какие бы предложения не приводились (например, предложение прекращения), они должны удовлетворять тому требованию, чтобы при них могла бы поддерживаться независимая от программиста система координат для описания процесса полезным и осуществимым способом.

Трудно закончить эти заметки без благодарностей. Могу ли я судить о том, кто оказал влияние на мои рассуждения? Совершенно очевидно, что не обошлось без влияния Peter Landin и Christopher Strachey. Наконец, я хочу отметить (я помню это совершенно точно), как Heinz Zemanek на встрече «pre-ALGOL» в начале 1959 г. в Копенгагене предельно ясно выразил свои сомнения в том, должен ли оператор go to трактоваться как такой же синтаксический базис, как оператор присваивания. До некоторой степени я виню себя за то, что не имел тогда представления о значимости его замечания.

Замечания о нежелательности оператора go to далеко не новы. Я помню, что читал четкие рекомендации ограничивать использование оператора go to аварийным выходом, но не помню точно, где, вероятно, это было сделано C. A. R. Hoare. В [1, Sec. 3.2.1.] Wirth и Hoare вместе делают замечание в том же направлении, мотивируя конструкцию выбора: «Как и условия, она отражает динамическую структуру программы более ясно, чем оператор go to и переключатели и она устраняет необходимость введения в программу большого числа меток.»

В [2] Guiseppe Jacopini, кажется, доказывает (логически) ненужность оператора go to. Упражнения по более или менее механическому переводу произвольной схемы алгоритма в схему без переходов, однако, не рекомендуются. При этом не ожидается, что результирующая схема будет более понятной, чем исходная.

Ссылки:

1. Wirth, Niklaus, and Hoare C. A. R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), --">
стр.

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.