Опубликован: 06.09.2005 | Доступ: свободный | Студентов: 11879 / 755 | Оценка: 3.98 / 3.46 | Длительность: 12:50:00
ISBN: 978-5-9556-0025-3
Лекция 15:

Технология программирования и отладки

< Лекция 14 || Лекция 15: 123
Аннотация: Методы и правила надежного программирования. Создание, документирование, тестирование и отладка программ.

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

Советы по технологии написания быстро отлаживаемых программ

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

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

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

Если же на этапе выбора алгоритма все-таки была допущена ошибка, то программу придется писать заново. При этом некоторые блоки старого варианта (например, ввод/вывод1Впрочем, довольно часто при выборе нового алгоритма формат внутреннего представления данных меняется кардинально, так что переделывать блок ввода все равно придется. ) могут не зависеть от выбора алгоритма, тогда переписывать их не нужно. Но основной алгоритм все-таки необходимо исправить.

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

Далее мы перечислим общеизвестные правила, которые помогут вам минимизировать затраты времени и сил при написании программы.

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

Имена, имена, имена...

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

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

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

Совет 2. Старайтесь давать основным переменным говорящие имена. Ясно, что безликие rez1 и rez2 несут в себе гораздо меньше информации, чем, скажем, dlina и shirina. Однако не стоит заводить очень длинные - более 6-7 символов - имена, поскольку это, во-первых, затормозит написание программы, а во-вторых, повысит вероятность возникновения "очепяток". Стоит использовать сокращения, короткие синонимы, русские слова (русские по смыслу и прочтению, однако латинские по написанию).

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

При выборе имен переменных стоит также пользоваться интуитивно знакомыми вам условностями. Например, i и j обычно служат вспомогательными счетчиками, m и n чаще всего хранят размерность, а x и y - координаты. Лучше не отступать от привычных вам сокращений и обозначений, даже если они и не являются общепринятыми.

Совет 3. Имена функциям и процедурам также нужно давать говорящие, причем здесь ограничения на длину гораздо мягче: до 10-15 символов. Вряд ли ваша программа будет обращаться к процедурам и функциям столь же часто, как к переменным, поэтому здесь на первый план выходит наполнение имен подпрограмм объяснением выполняемых ею операций. Лучше не полениться и набрать два-три раза, например schet_min_zatrat, чем путаться во время отладки между schet_z и schet_p. Удобнее всего, если имена подпрограмм соответствуют выполняемым ими шагам алгоритма той или иной степени детализации: в этом случае легче выявить ошибки процесса кодирования и разработки (неправильный порядок операций, преждевременная остановка и т.п.).

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

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

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

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

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

< Лекция 14 || Лекция 15: 123
Евгения Поздеева
Евгения Поздеева
Ольга Стебакова
Ольга Стебакова

Вот фрагмент лекции 5 (статья 4):

Проверка множества на пустоту может быть осуществлена довольно просто:

pusto:= true;   for i:= 1 to N do 

if set_arr[i] then begin pusto:= false; break end; {мне кажется здесь должно быть так:

if set_arr[i]<>0 then begin pusto:= false; break end;}

Хотелось бы знать это ошибка в теории или я просто не поняла лекцию?