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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

 

КОММЕНТАРИИ

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОГЛАВЛЕНИЕ

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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