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

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

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

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

Первым делом проверяйте программу за столом.

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

Два типа сообщений об ошибках обычно свидетельствуют о присутствии в программе неопределенных переменных: ПЕРЕПОЛНЕНИЕ и ПОТЕРЯ ЗНАЧИМОСТИ. Этими словами характеризуются соответственно слишком большие и слишком малые числа. Нынешние возможности ЭВМ таковы, что практически любые вычисления могут выполняться ими без переполнения или потери значимости. Поэтому, если заведомо известно, что программа не имеет дела с очень большими или крайне малыми числами, то переполнение или потеря значимости служат обычно достоверными признаками наличия в программе неопределенных переменных.

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