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

СТИЛЬ ПРОГРАММИРОВАНИЯ

Цель программирования — не создание программы,

 а получение  результатов вычисления.

Кодирование, увы, само по себе ничего

не стоит  — существенны результаты!

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

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

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

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

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

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

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

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

СТАНДАРТИЗАЦИЯ  СТИЛЯ

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

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

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

Однако процессу стандартизации свойственны и недостатки: применение стандартов может замедлить будущее  развитие средств программирования; стандарты могут оказаться ограниченными или слишком громоздкими для универсального применения.

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

Хороший набор стандартных  приемов может стимулировать  будущие разработки, поскольку позволит сконцентрировать внимание на действительно  новых задачах. Например, не надо больше думать о выборе способа записи циклов.

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

КОММЕНТАРИИ

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

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

Когда следует писать комментарии? Хорошее правило — включать комментарии  в процессе написания программы. Именно в это время вы в наибольшей степени вникаете во все детали программы. Редко удается получить удовлетворительные результаты при более поздней  вставке комментариев: при этом приходится вспоминать, что следует прокомментировать. Общее правило при написании  комментариев — чем больше комментариев, тем лучше. Очень немногие программы  бывают перенасыщены комментариями.

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

Хорошие комментарии написать непросто. Так как цель комментариев — облегчить понимание программы, — они должны быть так же хорошо продуманы и проработаны, как  и кодировка программы. Многие комментарии  могут быть перенесены из первоначальной разработки проекта, если он создается методом сверху вниз (см. далее). Спецификации проекта описывают программу, и часто можно воспользоваться некоторыми из них для составления комментариев. Комментарии нужны как на стадиях проектирования и отладки программы, так и позже. В связи с этим бессмысленно вставлять комментарии после того, как программа завершена. Это подобно изучению маршрута по карте после окончания путешествия. Если вы испытываете трудности при составлении комментариев для описания того, что вы делаете, то скорее всего вы "не ведаете, что творите".

Существуют три типа комментариев: вводные, оглавления и пояснительные.

ВВОДНЫЕ КОММЕНТАРИИ

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

1. Назначение программы. 

2. Указания по вызову  программы и ее использованию. 

3. Список и назначение  основных переменных или массивов.

4. Указания по вводу-выводу. Список всех файлов.

5. Список используемых  подпрограмм. 

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

7. Сведения о времени  выполнения программы. 

  8. Требуемый объем памяти.

9. Специальные указания  оператору. 

10. Сведения об авторе.

  11. Дату написания программы.

Эти данные необходимы для  документирования программы, и наилучшим  местом для размещения этой информации является сама программа. На рис. 1.1 показан  пример подобной документации.

Делайте вводные комментарии.

ОГЛАВЛЕНИЕ

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

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

ПОЯСНИТЕЛЬНЫЕ КОММЕНТАРИИ

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

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

Считается, что программы  на языках высокого уровня легко читаются и как бы сами себя документируют, однако часто логика одного программиста — автора программы — не очевидна для другого. В таких случаях (а  их значительно больше, чем кажется) роль комментариев неоценима. Комментарии следует давать в таких местах программы, которые хочется пояснить, когда вы знакомите кого-либо со своей программой.

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

/* ПРОВЕРИТЬ, ЯВЛЯЕТСЯ  ЛИ ВЕЛИЧИНА ОТРИЦАТЕЛЬНОЙ */

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

/* ВЫПОЛНИТЬ ОБРАБОТКУ  ОТРИЦАТЕЛЬНОГО САЛЬДО (СУММАРНЫЕ  РАСХОДЫ ПРЕВЫШАЮТ ДОХОДЫ.) */

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

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

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

РАСПОЛОЖЕНИЕ  КОММЕНТАРИЕВ

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

1. Чтобы поместить в  этот прямоугольник комментарии. 

2. Чтобы сгруппировать  множество команд. Это достигается  расположением до и после этой  группы команд строк комментариев, заполненных специальными символами. 

3. Чтобы указать, что  комментарий относится к нескольким  строкам программы. 

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

Если комментарии включают в строку текста программы, то используют установленную позицию (колонку) для  начала каждого комментария. Например, начинают комментарии с 40-й позиции, оставляя для текста программы позиции  с 1-й по 39-ю. В строке комментариев для простоты распознавания желательно начинать текст комментариев, отступив от позиции начала строк операторов программы.

Для структурированных программ обычно требуется меньше комментариев, чем для неструктурированных, так  как программы первого вида понятнее и в них меньше переходов.

         Однако очевидно, что в этом случае надо не комментировать, а перепрограммировать — упорядочить программу.

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

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

ПРАВИЛЬНЫЕ КОММЕНТАРИИ

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

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

ПРОПУСК СТРОК

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

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

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

ПРОБЕЛЫ

В языках программирования пробелы довольно часто ставятся произвольно. Действительно, в изъятии  пробелов из программы не больше смысла, чем в том, чтобы их убрать из текста. Что вы скажете, например, о такой  фразе: Явсегдамогунаписатьнечтоподобноеивысможетепрочестьноэтопотребуетотвасслишкоммногоусилий.

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

Можно написать такой оператор: DO10I= 1,23,2

Но вот такой оператор читать значительно легче: DO 10 I = 1, 23, 2

Широкое использование пробелов существенно облегчает чтение программы. Ставьте пробелы между элементами списка данных, а также до и после  операций +, —, =. Иногда желательно отделять пробелами операции (*,/). Пробелы можно также использовать для указания приоритета операций. Например, запись вида 1 + А*В предпочтительнее, чем вводящее в заблуждение выражение 1 + А * В.

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

ВЫБОР ИМЕН ПЕРЕМЕННЫХ

Имена переменных должны быть выбраны так, чтобы они наилучшим  образом определяли те величины, которые  они представляют. Если ограничения  на длину имени отсутствуют, используйте  имена настолько длинные, насколько  это нужно, но не длиннее, чем необходимо. Например, в операторе  X = Y+Z имена переменных выбраны неудачно, поскольку совсем не использована мнемоника. Такая запись оператора PRICE=COST+PROFIT намного лучше.

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

Существуют некоторые  запреты, которые необходимо помнить  при выборе имен переменных и меток. Избегайте схожих по виду имен, их неестественных написаний (как phone и fone) и подобных по написанию символов (АХ10 и АХIO). Если нужно использовать числа в именах переменных, лучше писать их в конце имени. Различие имен должно быть всегда явно ощутимым. В этом смысле имена, сходные по звучанию, виду или составу букв, отличаются мало. Когда имя содержит избыточную информацию, это тоже плохо. Например: FOUR = 12/5

Здесь переменная FOUR имеет  два различных значения: величины 4 и величины, помещенной в ячейку FOUR.

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

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

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

При использовании различных  типов переменных: целых, действительных, комплексных, символьных — программист  часто попадает в затруднительное  положение. Однако трудности легко  преодолеть, если следовать определенным соглашениям при поименовании переменных различных типов. Например, в программе с несколькими комплексными переменными все имена этих переменных могут начинаться с буквы С или аббревиатуры СМР. Этот префикс будет напоминать вам, что переменная комплексная. Подобный метод может быть применен для облегчения идентификации файлов.

Начинайте имена целых  переменных с одной из следующих  букв: /, /, К, L, М, N. Использование этих букв для представления целых  переменных настолько обычно и общепринято, что полезно следовать этому  на практике.

Если язык программирования допускает разделитель в именах переменных, то его следует использовать. Например: имя COSTPLUS    следует представлять как    COST-PLUS

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

Правильно выбранные имена переменных уменьшают необходимость комментариев.

ИМЕНА ФАЙЛОВ

        При  работе с файлами для идентификации  каждого файла разумно выбрать  какой-либо префикс или суффикс.  Этот префикс или суффикс вы  сможете использовать в названии  младших единиц этого файла.  В рассматриваемом примере MASTER используется как префикс.

FILE SECTION.

FD MASTER-FILE,

. . .

. . .

01 MASTER-RECORD.

     03 MASTER-NAME       PICTURE X(20).

    03 MASTER-ADDRESS    PICTURE X(40).

     03 MASTER-NUMBER     PICTURE 9(08).

Если каждый файл имеет  свой префикс, то намного легче читать программу. Этот префикс помогает определить соответствующее поле при распечатке программы и указывает, какие  поля и рабочие области связаны  логически. Еще одно соглашение состоит  в том, что имена файлов должны содержать слово FILE, а имена записей  — слово RECORD.

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

Указанный прием позволяет  различать по префиксам идентичные имена, такие, как поле дат.

Например:

MASTER-DATE

TRANSACTION-DATE

REPORT-DATE

Здесь каждое из трех различных  полей дат идентифицируется по своему префиксу. Если вы не воспользуетесь приведенными здесь рекомендациями, то будете вынуждены применять различные сокращения, например DATE, DTE, DAT, которые позволят различать поля.

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

СТАНДАРТНЫЕ СОКРАЩЕНИЯ

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

   MSTR

   MAST

   MST

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

Для тех, кто хочет сократить  длину идентификатора с целью  экономии объема памяти или вынужден делать это из-за ограничений, накладываемых на длину имени, предлагается набор правил сокращения, который поможет обеспечить удобочитаемость программ. Эти правила, разработанные Микаэлом Джексоном (Datamation, апрель 1967), заключаются в следующем:

1. Каждое значащее слово  в имени подлежит сокращению, общее число слов в сокращенном  имени должно быть не более  трех.

2. В аббревиатуру всегда  должны включаться начальные  буквы слов.

3. Согласные важнее гласных. 

4. Начало слова важнее  его конца. 

5. Аббревиатура должна  включать в себя от 6 до 15 букв.

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

ПЕРЕНОС

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

       Если  вы записываете оператор на двух строках, делайте перенос после знака операции. Вот случай небрежного переноса:

 А = В—С 

—(D+2)

        Гораздо  лучше перенести так: 

 А=В—С—

(D+2)

        Во  втором примере знак “минус”,  записанный на первой строке, сообщит читателю о том, что  оператор продолжается на следующей  строке. Кроме того, если вторая  строка оператора будет случайно  выброшена, то в первом примере  это пройдет бесследно, тогда как во втором будет обнаружена синтаксическая ошибка.

УПОРЯДОЧЕНИЕ  СПИСКОВ ПО АЛФАВИТУ

Языки программирования включают много списков имен переменных, причем порядок расположения имен в списке определяется самим программистом. Рассмотрим два типа списков: списки имен переменных при объявлении типа переменных и списки параметров процедуры.

Упорядочивание имен в  списке облегчает поиск имени. Приведем в качестве примера два списка:

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