Материал: Освой самостоятельно программирование для MS Access 2002 за 24 часа [П.Киммел]
17: End Select
18:
End Function
14.4 содержит третий (вероятно, самый удачный) вариант
|ции анализа уровня интеллекта. (Возможно, после знакомства с улуч-
шенным кодом незаметно повысится и ваш собственный IQ.) Текстовые
константы вынесены в отдельный блок, им присвоены конкретные на-
именования. Строки конструкции Select Case подвергнуты тщатель-
ному выравниванию с помощью отступов и выглядят безупречно.
Как упростить код
Существует целый ряд стратегий, позволяющих облегчить работу с программным
кодом. Хорошо, если эти простые правила, перечисленные ниже, со временем станут
настолько привычными, что вы сможете руководствоваться ими, не затрудняя себя
лишними раздумьями.
• Избегайте использования вложенных условных конструкций.
• Чаще используйте процедуры и функции.
• Создавайте короткие и уместные процедуры.
Применяйте указанные правила на практике, и код заметно упростится. Вы смо-
жете без труда вносить в него необходимые исправления и повторно использовать го-
товые фрагменты в новых проектах.
„Нет" — вложенным условным конструкциям
К сожалению, существует практика создания конструкций Select Case и If
Then, вложенных одна в другую. В подобных случаях код приобретает такой вид:
If
Then
If Условие2 Then
End If
Else
If УсловиеЗ Then
Условие4 Then
If Условие5 Then
End If
Else
End If
End If
Это еще не самый плохой вариант — все может быть гораздо хуже. Стоит забыть об
использовании отступов и добавить побольше строк, описывающих последовательность
действий для каждого из условий, — и код максимально будет напоминать подгоревшую
молочную кашу. И вновь, повторюсь, никого не следует подозревать в злых намерени-
ях — обычные небрежность, халатность и легкомыслие. Одна и та же программа может
выглядеть и вопиюще скверно, и просто здорово — все зависит от профессионализма,
последовательности в применении названных правил, от элементарной аккуратности.
Новый термин
Разложение на элементарные операции подобно разложению на
множители в математике. В программировании это означает разбиение
повторяющегося кода на процедуры или классы, которые помещаются в
программу только один раз. Например, если один и тот же набор из 10
строк повторяется в программе несколько раз, переместите его в
процедуру и замените повторяющиеся строки вызовом этой процедуры.
14-й час. Стиль программирования: "Что такое хорошо, и что такое плохо" 245
Приведенный фрагмент легко переписать следующим образом:
If
Then
Call
Else
Call Процедура2
End If
реализует цепочку действий, выполняемых в том случае, если Усло-
становится истинным, а Процедура2 соответствует обратной ситуации. Создан-
ные процедуры также, в свою очередь, могут быть упрощены за счет построения до-
полнительных процедур и функций. Код, таким образом, становится понятным и со-
вершенно прозрачным.
„Да" — процедурам и функциям
Вынесение строк кода в отдельные блоки — процедуры и функции — упрощает за-
дачу сопровождения программы и повторного использования ее фрагментов. Рассмот-
рим конструкцию Select Case. Если вы разместите строки, обрабатывающие каж-
дый
случай
(case), в том же блоке, где размещено само выражение Select Case, воз-
можность повторного использования такого кода окажется ограниченной узким кон-
кретным контекстом. Взгляните на следующий фрагмент:
Select Case Условие
Case
Case
Case Else
End Select
Если вы введете строки для обработки всех случаев здесь же, непосредственно в
теле выражения Select Case, о возможности повторного применения кода придется
просто забыть. Но если каждому случаю будет поставлена в соответствие отдельная
процедура, вы сможете гораздо легче использовать их в текущем или новых проектах.
Разумеется, нельзя воспринимать подобный совет как догму — это всего лишь пре-
достережение. Если код Select Case настолько же прост, как тот, который приведен
в листинге 14.4, дополнительные процедуры не потребуются. Но если вы видите, что
условная конструкция имеет тенденцию к усложнению, исследуйте возможность
членения ее на части с помощью процедур и функций.
Создавайте короткие и уместные процедуры
Ранее уже говорилось о том, что удобно, называя процедуры, использовать наиме-
нования, состоящие из глагола, который описывает выполняемую операцию, и суще-
ствительного, указывающего на объект воздействия. Из этого правила вытекает сле-
дующее требование: процедура должна выполнять только те операции, о которых сви-
детельствует ее название.
Часто, например, возникает ситуация, когда необходимо снабдить программу до-
полнительными средствами обработки ошибок. Далее будет рассмотрена функция, ко-
торая открывает файл и возвращает номер открытого файла. Если задача требует, что-
бы файл существовал, целесообразно написать не одну, а две функции, одна из кото-
рых вызывает другую. Изучите текст листинга 14.5.
Листинг 14.5. Пример построения иерархии функций
1: Function
FileName
As
String )
2: DoOpenFile = FreeFile
3 : Open FileName For Random As #DoOpenFile
4 : End Function
5:
As Double
246
Часть V. Программирование и базы данных Access
6: Function
FileName As String ) As Boolean
7: FileExists If (Len( Dir( FileName ) ) > 0)
8: End Function
9:
ByVal FileName As String ) As Double
11: If
Then
OpenFile =
13: Else
' процедура обработки ошибок
15: End If
Function
Первая из функций, DoOpenFile, текст которой расположен в строках 1-4,
непосредственно решает задачу, открывая файл и возвращая его номер в
виде числа двойной точности. Вторая функция, FileExists, находящаяся
в строках
выполняет проверку существования файла с заданным име-
нем. Внешняя функция, OpenFile, выполняет операции по проверке су-
ществования файла и в случае успеха вызывает функцию DoOpenFile. Об-
ращаться следует, разумеется, к функции OpenFile. Результат получается
простым и удобным.
Таким образом, создаются внутренние и внешние функции. Вызываемая функция
обеспечивает обработку ошибок, а внутренняя функция, с префиксом Do, непосредст-
венно выполняет операцию.
Как комментировать код
Работая над черновиком программы, вы наверняка выдвигаете определенные
предположения о ее назначении. Уделите пару минут, чтобы зафиксировать их в виде
примечаний к коду. Гораздо проще комментировать текст профаммы во время ее на-
писания, нежели позже, когда придется восстанавливать в памяти ход своих рассуж-
дений. Вот несколько простых советов по поводу написания комментариев.
• Используйте полноценные предложения.
• Комментируйте длинные фрагменты кода.
• Сопровождайте примечаниями неоднозначные участки кода и фрагменты,
заимствованные из других источников.
Используйте полноценные предложения
Этот совет, считаем, вполне понятен. Не ленитесь выражать свою мысль в виде за-
конченных предложений на родном языке. Они помогут в ходе дальнейшей работы
над профаммой и пригодятся при написании руководств.
Хорошо известна профамма JavaDoc.exe, которая автоматически гене-
рирует документацию к профамме, читая ее исходный текст на языке
Java. Вполне возможно, вам удастся найти подобное средство, ориен-
тированное на применение в среде VBA.
Комментируйте длинные фрагменты кода
ЕСЛИ процедура или функция содержит более трех-пяти строк, подумайте о напи-
сании нескольких предложений, которые поясняют ваш замысел, раскрывают назна-
чение кода и оговаривают особые условия его использования.
14-й час. Стиль программирования: "Что такое хорошо, и что такое плохо" 247
Сопровождайте примечаниями
неоднозначные участки кода
Если код предусматривает выполнение особо точных операций либо заимствован
из внешнего источника, не лишайте себя возможности ввести пару-тройку примеча-
ний. При комментировании чужого кода обязательно укажите полное наименование
источника, из которого он получен, наименование файла или документа, номер вер-
сии, фамилию автора, дату опубликования, номера страниц и т.п. Вполне вероятно,
что со временем вам потребуется вновь обратиться к тому же источнику за очередной
редакцией кода, разъяснениями или помощью в преодолении нештатных ситуаций.
О возможностях повторного
использования кода
Индустрия, основанная на принципах повторного применения программного кода,
располагает миллиардами долларов. Имя ей —
програм-
мирование. Собственно говоря, одна из предпосылок появления этой отрасли была
связана с поисками ответа на вопрос, как добиться возможностей многократного ис-
пользования ранее созданного программного кода. (Подробнее вопросы объектно-
ориентированного программирования освещены в главе "21-й час. Основы програм-
мирования
Впрочем, решить подобную задачу можно не только в рамках
объектной парадигмы. И ниже рассказано, как этого достичь.
Код, который следует применить, написан — т.е. вам уже не нужно этим заниматься.
Он наверняка прошел стадию отладки и тестирования — стало быть, если вы не соби-
раетесь его исправлять, повторная отладка не потребуется. Поскольку код ранее уже
кем-то использовался (может быть, даже вами), не исключено, что он способен полно-
стью решить вашу конкретную проблему. Наконец, если вставить подобный код в не-
кую "обрамляющую" его процедуру, вам потребуется протестировать только эту проце-
дуру. Листинг 14.5 иллюстрирует сказанное. Если вы позаимствовали готовую функцию,
подобную DoOpenFile, а затем облекли ее в "оболочку", схожую с OpenFile, достаточ-
но будет проверить, насколько правильно работает новая, внешняя, функция.
Важно как можно раньше утвердить систему именования процедур и
функций и последовательно ее придерживаться. Объяснения просты:
если вы решили изменить название функции, придется пролистать
текст программы и отредактировать все ссылки на эту функцию.
Исправленный код, разумеется, нуждается в тестировании. Впрочем,
существует иной способ достижения цели. Представьте, у вас есть
процедура. Если перед ее именем ввести префикс (скажем,
Do),
а затем
создать новую, "обрамляющую", процедуру, дав ей имя прежней, весь
код останется в неприкосновенности, и тестировать доведется только
вновь созданную процедуру.
Чем более лаконична процедура или функция, чем более четкими и понятными
именами и комментариями она снабжена, тем выше вероятность ее повторного ис-
пользования. Словом, если вы прислушаетесь к советам, которые прозвучали в ходе
этого занятия, вам удастся дать многим программным творениям — своим и чужим —
вторую жизнь, тем самым облегчив собственную.
248 Часть V. Программирование и базы данных Access
Советы по тестированию и отладке кода
В главах "17-й час. Отладка кода" и "18-й час. Обработка ошибок во время вы-
полнения программы" содержатся подробные сведения по вопросам тестирования и
отладки программного кода, поэтому рассматривать в данный момент нецелесообраз-
но. Дадим лишь некоторые советы-предостережения.
Исправляя код, обязательно подвергайте его повторному тестированию даже в том
случае, если изменения кажутся незначительными; в противном случае вы рискуете
собственной профессиональной репутацией. При отсутствии специальных средств
контроля версий программного продукта ведите журнал, в котором в хронологическом
порядке перечисляются выявленные ошибки и внесенные исправления. Минуты, по-
траченные сейчас, впоследствии обернутся часами сэкономленного времени и массой
сохраненных нервных клеток.
Еще раз о работе с данными
Решить проблему удобочитаемости программного кода могут также применяемые
вами способы работы с данными. Вот несколько кратких советов по этому поводу.
• Используйте именованные константы вместо литеральных значений.
• Проясняйте назначение и смысл параметров процедур и функций с помо-
служебных слов
ByRef и Optional.
• Ограничьте применение глобальных переменных.
Если вам приходится использовать литеральные символьные или числовые кон-
станты, определите их явно с помощью служебного слова Const и четких, понятных
наименований. Характерный пример приведен в тексте листинга 14.4.
Чтобы гарантировать неизменность значения параметра, переданного функции,
используйте служебное слово ByVal. Если, в соответствии с вашим замыслом, значе-
ние аргумента может изменяться внутри функции, назначьте переменной
тор ByRef. Наконец, если аргумент в большинстве случаев принимает некоторое за-
ранее известное значение, обозначьте его как Optional. Пример использования слу-
жебного слова Optional приведем в листинге
Резюме
Как вы пишете собственные программы — дело личное. Единого универсального
способа оформления программного кода, увы, не существует, но какой-то вам все
равно придется избрать и последовательно использовать. Приняв определенную стра-
тегию действий, вы сможете освободить время, направив свои знания и энергию на
достижение более высоких целей.
На этом занятии вы узнали о том, как с помощью упрощения и уменьшения размера
процедур и функций добиться возможности повторного использования собственного и
заимствованного кода. Мы обсудили схемы именования программных объектов: проце-
дуры и функции, например, удобно называть словосочетаниями, состоящими из глагола
и существительного. Расчленение многоуровневых управляющих структур на составные
части — еще один способ обеспечения удобочитаемости и управляемости кода. Столк-
нувшись с задачей изменения имени существующей функции, вы можете "облечь" ее
рамками новой, избежав при этом необходимости внесения многочисленных исправле-
ний и проведения исчерпывающего повторного тестирования.
час. Стиль программирования: "Что такое хорошо, и что такое плохо" 249