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

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

Заповеди программирования

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

Ниже об этих правилах - более подробно.

Заповеди ключай повторяющиеся строки кода твоего в функции

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

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

5 Sub Test ( )

6.: Dim SaleAmount As Double 1\ Dim TotalSale As Double

SaleAmount = 100 9: TotalSale = CalculateTotalSale(SaleAmount) 10: Dim WashingtonSalesTax As Double 11: WashingtonSalesTax = .08

12: TotalSale = CalculateTotalSale(SaleAmount, WashingtonSalesTax ) 13: End Sub

Изменения, внесенные нами в текст программы, служат цели пояснения

различий между процедурами и функциями. Код функции с прежним

именем - CalculateSalesTax - начинается со служебного слова Function и завершается им. Теперь вы можете не использовать параметр TotalSale его роль исполняет возвращаемый аргумент, имя которого совпадает с названием функции (см. строку 2).

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

Заповедь 2: Выражайся лаконично

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

Заповедь 3: Ограничивай число аргументов твоих

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

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

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

Заповедь 4: Проясняй мысль твою посредством

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

квалификаторы, чтобы до конца прояснить свой замысел. Заповедь 5: Обусловливай решения твои

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

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

адекватные действия.

Зачастую автор и пользователь программы - одно и то же лицо.

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

безупречным.

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

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

1: Function е( ByVal FileName As String ) As Double 2: Условие: файл FileName должен существовать 3: Debug.Assert Len ( Dir( FileName ) ) > 0 4: Open FileName for Input As #OpenFile

5: End Function

Как мы говорили, условие должно снабжаться комментарием, и в примере таков имеется (см. строку 2). Впрочем, одной констатации мало -программа должна позаботиться о проверке выполнения требования (в нащем примере данная роль возложена на команду Debug.Assert Len( Dir ( FileName ) ) > 0 в строке 3). Если функция Dir определит, что файла не существует, т.е. возвратит строку нулевой длины, выполнение программы завершится в строке 3.

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

Заповедь 6: Не ленись комментировать код твой

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

А теперь все хором!

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