Программирование

ext-align:justify">2) REAL I, AMOUNT, SIZE, K, BETS

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

INTEGER BETA, COST, DOBT, KEP, PRICE, Z

REAL AMOUNT, BETS, I, K, SIZE

Необязательно упорядочивать  имена всех переменных одного типа в одном операторе объявления типа. Часто бывает удобнее объединять логически связанные переменные.

INTEGER BUFFI, BUFF2, CHAR, TERMTR

INTEGER COST,  PRICE, TAX

Упорядочивайте списки по алфавиту.

 

СКОБКИ

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

Использование малого количества скобок	Использование дополнительных скобок
A*B*C/(D*E*F)	(A*B*C)/(D*E*F)
A*B/C*D/E*F	(A*B*D*F)/(C*E)
А**В**С	А**(В**С)
A/B/C/D	((A/B)/C)/D
А**В*С	(А**В)*С
X.GT.Y.OR.Q	(X.GT.Y) .OR. Q
A+B.LT.C	(А+В) .LT. С

 

Основное правило таково: в сомнительных случаях ставьте  скобки, — это не только сделает  программу более понятной, но и  предотвратит ошибки. Часто в логических выражениях скобки используют недостаточно, что приводит к ошибкам.

Скобки обходятся дешевле, чем  ошибки.

 

ОТСТУПЫ ОТ НАЧАЛА СТРОКИ

 

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

Текст без отступов:

IF (1< = 1) THEN FACTORIAL: = 1 ELSE BEGIN FACTORIAL": = 1;

FOR J:=2 UNTIL I DO FACTORIAL: = FACTORIAL * J

END;

Текст с отступами:

IF (I <= 1) THEN

   FACTORIAL: = 1

ELSE

   BEGIN

      FACTORIAL : = 1;

      FOR J:=2 UNTIL I DO

          FACTORIAL := FACTORIAL * J

   END;

        Циклы  — типичный случай использования  отступов. Примеры таких циклов  показаны ниже.

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

Отступы делают не только при  использовании циклов, их вводят и  для лучшей группировки команд.

Обычно используются последовательные отступы на три позиции. Этого  расстояния вполне достаточно, чтобы  указать абзац и сделать несколько  уровней отступа.

Для выявления структуры программы  используйте отступы.

Аналогичным приемом можно  воспользоваться при написании  арифметических операторов: располагать  в одной позиции все знаки  равенства:

SIGN=BASE*COUNT

COST= PAY+BONUS

Это также улучшает читаемость программы.

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

 

ВЫБОР ИМЕН РАЗДЕЛОВ

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

Название раздела должно отражать цель данного раздела, т.е. действия, которые в нем производятся. Кроме того, использование разделов обеспечивает удобное место для  комментариев. В начале каждого раздела  следует помещать комментарии с  объяснением назначения этого раздела.

 

НЕЧИТАЕМЫЕ ПРОГРАММЫ

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

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

Начинающие программисты думают, что они составляют программы  для машин. Опытные программисты знают, что пишут программы для  людей. Длинная цепочка людей будет читать большую часть этих программ. Вначале сам автор будет много раз читать и перечитывать программу, в то время пока пишет, тестирует и отлаживает ее. Затем все, кто должны использовать программу, будут перечитывать ее много раз. Мы учимся писать, читая. По-видимому, причина того, что мы таким же образом не учимся программировать (т.е. читая чужие программы), — недоступность большинства программ.

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

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

 

ЗАКЛЮЧЕНИЕ

 

Надеюсь, мне удалось показать, что небольшие усилия, которые  необходимо приложить для того, чтобы  сделать программу удобочитаемой, обходятся дешевле, чем издержки по пересмотру, обнаружению ошибок или переделке плохо написанной программы. Скорость разработки программного обеспечения— около десяти полностью отлаженных команд в день; небольшие затраты на улучшение читаемости программы были бы при этом очень полезны.

Хорошего программиста отличает способность писать удобочитаемые  программы. В оправдание плохо составленных программ обычно приводят два аргумента:

1. Это просто сделанная  на скорую руку черновая программа  ограниченного использования. 

2. Это провалившийся проект, который нет смысла дорабатывать.

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

Много говорилось о необходимости  полной документации. Если программы  удобочитаемы, то они сами становятся существенной составляющей документации. Таким образом, имеется еще один аргумент в пользу удобочитаемости  программ: программа — это часть  документации, точная и отражающая произведенные изменения. Таким  образом, в случае легкочитаемого входного языка можно сказать, что документация программы— это есть сама программа.

 

СОВЕТЫ ПРОГРАММИСТУ

Помните: программы читаются людьми.

Делайте комментариев больше, чем это кажется необходимым.

Используйте вводные комментарии.

Делайте оглавление в больших  программах.

Комментарии должны содержать  дополнительную информацию” а не перефразировать программу.

Располагайте комментарии  таким образом, чтобы это не делало программу менее наглядной.

Неправильные комментарии  хуже, чем их отсутствие.

Делайте пробелы для улучшения  читаемости программы.

Используйте имена с подходящей мнемоникой.

При наименовании файлов используйте  определенный префикс или суффикс.

Одного оператора в  строке достаточно.

Упорядочивайте списки по алфавиту.

Скобки обходятся дешевле, чем ошибки.

Для выявления структуры  программы используйте отступы.

Для выявления структуры  данных используйте отступы.