TraceMessage & vbCrLf Debug.Print Output End Sub

Анализ

l[ Листинг П.2 содержит текст процедуры трассировки. Добавьте ее в тот

I же модуль, который собираетесь проверять, и вы получите удобное средство тестирования. Если необходимо применить готовую процедуру трассировки в других базах данных, воспользуйтесь командами экспорта (FileExport File) и импорта (File=>lmport File) модуля.

В строке 3 объявляется переменная для хранения строки данных, форматируемой ниже (в строках 4-5) в соответствии с шаблоном ИмяФайла (НомерБлока) в ДатаВремя. Предопределенная константа vbCrLf содержит управляющие символы возврата каретки и перевода строки, позволяющие разбить одну логическую строку данных на несколько физических, которые с помощью команды Debug.Print отображаются затем в окне Immediate.

Другая версия процедуры Trace могла бы осуществлять вывод информации в журнальный текстовый файл. (Я, например, в свое время использовал обе.) Чтобы реализовать подобный код, необходимо открыть (Open) текстовый файл в режиме Append,

использовать команду Write для записи в него форматированной строки, а затем закрыть (Close) файл.

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

Верификация исходных условий

Без начальных условий и предположений программирование вообще невозможно.

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

Класс Debug в VBA содержит метод Assert. Функция Assert предполагает задание единственного параметра типа Boolean (проверяемого условия) и приостанавливает выполнение программы, если условие не выполнено. Собственно, это как раз то, что нужно. Assert играет роль блюстителя порядка . Если для корректной работы программы

необходимо выполнить определенное условие, Assert аккуратно за этим проследит.

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

вы намереваетесь обновить содержимое файла, то файл (это совершенно очевидно) должен существовать. Конечно, можно было бы написать, скажем, такую строку кода: If (Len( Dir( FileName ) ) > 0) Then

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

Debug.Assert Len( Dir( FileName } ) > 0 If (Len( Dir( FileName ) ) > 0) Then

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

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

Не используйте конструкции, подобные FileName)) > 0) Then, непосредственно. Заключите эту строку в тело функции и дайте последней четкое название, скажем. Function FileExists (ByVal File-Name As String) As Boolean. В этом случае код приобретет ясность и

будет удобным для чтения.

Во время отладки вместо задания точки останова в строке If Then достаточ-

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

лишь в случае возникновения какой-либо непредвиденной ситуации.

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

Использование соглашений

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

соответствующая проверка вами не предусмотрена.

Теперь вы можете сосредоточить внимание непосредственно на проблеме

(пополнения файла данными) и значительно уменьшить объем кода за счет исключения

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

разумеется, воспользоваться конструкцией верификации. Если условие верификатора не

выполнится, программист, допустивший оплошность и не проверивший факт существования файла, обязательно обратит внимание на верификатор и вспомнит о соглашении.

Соглашения - это неплохо, но лучше, если они будут подкреплены верификаторами

(как говорится, доверяй, но проверяй ). Собственно, сказанное справедливо и в том

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

незаменимо для групп программистов, не работающих в непосредственной близости,

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

Повторное использование кода отладки

Вспомогательный код (как и любой другой код) нуждается в отладке. Однако, приступая к новому проекту или модулю, вы не должны заново создавать и отлаживать, например Trace, Trap и Assert. Напишите подобные функции один раз, отладьте их, экспортируйте модуль в файл (скажем, Debug.bas), а затем импортируйте по мере необходимости в каждый новый проект.

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

Использование директив компилятора

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

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

это восстанавливать. Как же быть? На помощь приходят директивы компилятора.

Директивам компилятора в тексте программы предшествует символ фунта (#). Директивы компилятора - это инструкции, указывающие, что делать с тем или иным блоком кода во время его компиляции. Наиболее частое применение в них находят константы и условные управляющие структуры. Обычно с помощью служебного слова #Const задается именованная константа, а затем строится управляющая структура вида #if ... #End If, охватывающая блок кода и проверяющая с помощью значения константы, следует включать блок в версию исполняемого файла программы или нет.

Конструкция . . End If - это вовсе не то же самое, что #If . .. #End If. Первая представляет собой полноправную часть кода, а вторая действует лишь во время его компиляции.

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

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

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

5

True

Sub Test (

iConst DebuggingOn #If DebuggingOn Then

Debug.Assert SomeBooleanValue iEnd If End Sub

II Листинг 17.3 содержит пример верного с формальной точки зрения ис-I пользования директив компилятора. Поскольку значение константы De-buggingOn равно True, код строки 4 будет включен в откомпилированную версию программы. Если изменить значение константы DebuggingOn на False, при следующей компиляции строка 4 не будет включаться в исполняемый код. В любом случае (независимо от значения константы) строк 2, 3 и 5 в откомпилированном коде не будет.

Текст процедуры Test технически правильный, но он достаточно скромный в практическом отношении. Дело в следующем. Если вы будете действовать таким образом и далее, придется обрамлять конструкциями #if ... #End if буквально каждый вызов метода Assert и других отладочных функций. Поэтому более целесообразно заключить выражение верификатора в отдельную процедуру и обращаться к ней при необходимости. Листинг 17.4 показывает более удачный пример использования директив компилятора.