Progress-gl - В чем преимущество размещения объявления переменной в верхней части процедуры

Question

Я делаю Progress 4GL в течение 8 лет, хотя это не моя основная ответственность. Я делаю C++ и Java намного больше. При программировании на другом языке предлагается, чтобы объявление было близко к использованию. Однако с 4GL я вижу, что люди помещают объявление поверх файла. Это даже в стандарте кодирования.

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

Вопрос в том, почему это предлагается сделать в 4GL? В чем польза? Я знаю, что можно разместить объявление в любом месте файла, учитывая, что оно было объявлено до его использования.

Answer 1

Я думаю, что ответ заключается в том, чтобы сделать обзор или отсутствие его в рамках Progress 4GL.

Если вы привыкли к Java, скажем, и прочитать программу Progress 4GL, который выглядит как

DO: 
    DEFINE VARIABLE x AS INTEGER INITIAL 4. 
    DISPLAY x. 
END. 

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

Как я понимаю, все переменные прогресса, объявленные в теле программы, охвачены всей программой, если они не объявлены, находятся внутри внутренней процедуры или функции, и в этом случае они охвачены процедурой или функцией.

(Кстати, любые буферы по умолчанию [т.е. необъявленные], которые вы используете во внутренней процедуре/функции, привязаны ко всей программе, а не только к процедуре или функции, поэтому вам нужно быть очень осторожными при объяснении буферов в функциях, которые вы собираетесь использовать ot использовать рекурсивно).

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

Answer 2

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

Меньшие области применения легче тестировать, дают меньше возможностей конфликта пространства имен и меньше возможностей для ошибок.

Плотно облаченные именованные буферы особенно полезны при записи в базу данных, поскольку они исключают возможность наличия какой-либо другой части вашего кода, которая использует тот же буфер и вызывает блокировку общего доступа, то есть это не скомпилируется:

do for b-customer transaction: 
    find b-customer where .... exclusive... 
    ... 
end. 
... 
find b-customer... 

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

Все это просто базовое структурированное программирование , конечно. Это верно для каждого языка и принимается с 70-х годов.

Answer 3

«Причина», которую вы обычно видите переменные, определенные сверху, проста. Привычка. Именно так делались в старые добрые времена.

Много старого кода, или кода, написанного старыми окаменелостями, написано именно так. Неважно, язык.

Некоторые языки (COBOL пружины на ум) даже формализовали его.

Есть ли какие-либо преимущества для такого подхода?

Не особо. Думаю, вы могли бы утверждать, что «все они в одном месте и легко найти», но это не очень убедительно.

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