4.35. Предотвращение ошибок

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

Не применяйте непроверенных способов программирования. Имейте в виду, что любое новое средство можно считать эффективным лишь тогда, когда имеется твердая уверенность в том, что оно нормально работает. Используйте простейшие операторы. Не пытайтесь обхитрить компилятор или операционную систему. Они настолько сложны, что бывает необыкновенно трудно найти в них такое место, где можно нарушить синтаксические правила и все же продолжать получать верные результаты. Однако если даже предположить, что это удалось сделать/остается нерешенной другая проблема: как гарантировать работоспособность "хитроумной" программы в условиях новых версий или изменений машинного языка и операционной системы? Ведь изготовитель ЭВМ совсем не обязан над этим задумываться, а обнаружить старую ошибку © новых условиях чрезвычайно трудно, так как со времени написания программы может пройти 1—2 года.

Старайтесь не использовать принцип умолчания. Во всех языках программирования имеются некоторые стандартные значения неременных, которые компилятор присваивает им по умолчанию. Это экономит трудозатраты программиста, но чревато опасностями, потому что фирмы-изготовители время от времени изменяют систему умолчаний. Программист же при этом может предположить, что он неверно использовал оператор умолчания. Известен случай, когда фирма IBM, для которой характерно частое усовершенствование собственных языков программирования, в очередной обновленной версии языка ПЛ/1 изменила стандартную длину параметра для одного типа переменных. В результате такого изменения многие программы, написанные на этом языке, оказались неработоспособными. Следует отметить также, что механизм действия операторов умолчания в разных машинах различен. Поэтому, если желательно обеспечить независимость программы от конкретной ЭВМ, то лучше избегать излишне частого использования операторов умолчания.

Никогда не допускайте зависимости работы программы от до-€товерности данных. Не следует полагаться на то, что информация, используемая программой, всегда будет вводиться в нужном виде или в заданных пределах изменения. Необходимо организовывать контроль данных при вводе для того, чтобы убедиться в нх правильности. Данные всегда ведут себя в полном соответствии с законом Мэрфи, который гласит: "Все, что может испортиться, портится". Ошибки в них могут вызываться нарушением инструкций, по вводу данных, опечатками при подготовке либо сбоями устройств ввода-вывода. Если такого контроля не проводить, то программа будет периодически самым таинственным образом приходить в неработоспособное состояние. И хотя после тщательного анализа ошибки будет показано, что она вызвана входными данными, и программа, и программист прослывут сомнительными.

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

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

4.34. Время, необходимое для отладки || Оглавление || 4.36. Заключение4


Услуги