Я новичок в программировании VBA. Я думаю, что я видел это где-то, но я полностью забыл, где я видел это. Может быть, я слышал это от кого-то.
Мой вопрос: влияет ли количество комментариев и пробелов в VBA на производительность кода?
Я думаю, что это должно быть одинаково в Excel и Access, но я не хочу предполагать, поэтому я собираюсь указать, что я использую Access 2003.
Вы можете заметить, что VBA анализируется в исполняемые токены во время редактирования, а не во время выполнения.
Несколько встроенных пространств скомпилированы как один токен n-пространства, так что они могут быть повторно отображены для редактирования, но на самом деле они являются просто одним токеном в скомпилированном коде. Так что не имеет значения, сколько пробелов вы ставите между словами. 100 равно 1.
Так что это «Правильное построение» эффективно удаляет все пробелы, когда вы заканчиваете редактирование (а не когда вы его запускаете).
Попробуй сам. Поместите несколько лишних пробелов в конец строки, перейдите к следующей строке, затем вернитесь назад и пробелы исчезнут. Также обратите внимание, что если вы попытаетесь ввести неверный код, он будет жаловаться, пока вы его не исправите. Это признак раннего разбора и токенизации.
Таким образом, ответ на ваш вопрос заключается в том, что при выполнении кода нет лишних пробелов, поскольку код предварительно скомпилирован, поэтому он НЕ МОЖЕТ влиять на скорость.
Я думаю, что «Правильное построение» - действительно классная штука. Это лучший из интерпретатора времени выполнения и быстрого компилятора в одном!
Синтаксический анализатор на компьютерном языке Forth делал что-то похожее в том, как он работал, но, конечно, он не был правильным редактором конструкции. Я всегда надеялся добавить один к этому.
Из MSDN MS-VBAL Лексические правила
Также помните, что имена переменных и констант не существуют в скомпилированной программе.
3.2.1 Физическая линейная грамматика
module-body-physical-structure = *source-line [non-terminated-line] source-line = *non-line-termination-character line-terminator non-terminated-line = *non-line-termination-character line-terminator = (%x000D %x000A) / %x000D / %x000A / %x2028 / %x2029 non-line-termination-character = <any character other than %x000D / %x000A / %x2028 / %x2029>Реализация МОЖЕТ ограничить количество символов, допустимых в физической строке. Значение модуля, который содержит любые физические строки, которые превышают такой предел реализации, не определено этой спецификацией. Если <module-body-Physical Structure> завершается с <non-terminated-line>, то реализация МОЖЕТ обрабатывать модуль так, как если бы за <non-terminated-line> сразу следовал <line-terminator>.
В целях интерпретации текста программы VBA тело модуля (раздел 4.2) рассматривается как набор логических строк, каждая из которых может соответствовать нескольким физическим строкам. Эта структура описывается грамматикой логической линии. Конечными символами этой грамматики являются кодовые точки символов Unicode.
3.2.2 Грамматика логической линии
module-body-logical-structure = *extended-line extended-line = *(line-continuation / non-line-termination-character) line-terminator line-continuation = *WSC underscore *WSC line-terminator WSC = (tab-character / eom-character /space-character / DBCS-whitespace / most-Unicode-class-Zs) tab-character = %x0009 eom-character = %x0019 space-character = %x0020 underscore = %x005F DBCS-whitespace = %x3000 most-Unicode-class-Zs = <all members of Unicode class Zs which are not CP2-characters>Реализация МОЖЕТ ограничить количество символов в <расширенной строке>. Для простоты спецификации удобно иметь возможность явно ссылаться на точку, которая непосредственно предшествует началу логической строки, и точку, непосредственно предшествующую конечному ограничителю строки логической строки. Это достигается с помощью <LINE-START> и <LINE-END> в качестве терминальных символов грамматик VBA. <LINE-START> определяется так, чтобы непосредственно предшествовать каждой логической строке, а <LINE-END> определяется как замена <line-terminator> в конце каждой логической строки:
module-body-lines = *logical-line logical-line = LINE-START *extended-line LINE-ENDПри использовании в определении правила ABNF <LINE-START> и <LINE-END> используются для указания требуемого начала или конца <логической строки>.
Синтаксис программ VBA легче всего описать с помощью лексических токенов, а не отдельных символов Юникода. В частности, появление пробелов или продолжений строк между большинством синтаксических элементов обычно не имеет отношения к синтаксической грамматике. Синтаксическая грамматика значительно упрощается, если ей не нужно описывать такие возможные пробелы. Это достигается с помощью лексических токенов (также называемых просто токенами), которые абстрагируются от пробелов в качестве терминальных символов синтаксической грамматики. Лексическая грамматика определяет интерпретацию <module-body-lines> как набора таких лексических токенов.
Терминальными элементами лексической грамматики являются символы Юникода и элементы <LINE-START> и <LINE-END>. Как правило, любое имя правила лексической грамматики, которое пишется всеми прописными буквами, также является лексическим токеном и терминальным элементом синтаксической грамматики VBA. Цитируемые ABNF правила буквального текста также считаются лексическими токенами синтаксической грамматики. Лексические токены охватывают любые пробельные символы, которые непосредственно предшествуют им. Обратите внимание, что при использовании в лексической грамматике правила литерального текста в кавычках не рассматриваются как токены, и, следовательно, любые предшествующие пробельные символы являются значительными.
3.3.1 Разделитель и специальные токены
WS = 1*(WSC / line-continuation) special-token = "," / "." / "!" / "#" / "&" / "(" / ")" / "*" / "+" / "-" / "/" / ":" / ";" / "<" / "=" / ">" / "?" / "\" / "^" NO-WS = <no whitespace characters allowed here> NO-LINE-CONTINUATION = <a line-continuation is not allowed here> EOL = [WS] LINE-END / single-quote comment-body EOS = *(EOL / ":") ;End Of Statement single-quote = %x0027 ; ' comment-body = *(line-continuation / non-line-termination-character) LINE-END<special-token> используется для идентификации отдельных символов, имеющих особое значение в синтаксисе программ VBA. Поскольку они являются лексическими токенами (раздел 3.3), этим символам могут предшествовать символы пробела, которые игнорируются. Любое вхождение одного из цитируемых элементов <special-token> в качестве элемента грамматики в синтаксической грамматике является ссылкой на соответствующий токен (раздел 3.3).
<NO-WS> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, не должны предшествовать никакие пробельные символы. <NO-LINE-CONTINUATION> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, не должен предшествовать пробел, который включает в себя любые последовательности <linecontinuation>.
<WS> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, должен предшествовать один или несколько символов пробела.
<EOL> используется в качестве элемента синтаксической грамматики для именования токена, который действует как маркер "конца оператора" для операторов, которые должны быть единственным или последним оператором в логической строке.
<EOS> используется в качестве терминального элемента синтаксической грамматики для именования токена, который действует как маркер "конца утверждения". Как правило, конец оператора помечается символом <LINE-END> или двоеточием. Любые символы между <single-quote> и <LINE-END> являются текстом комментария, который игнорируется.
Пробельные символы и комментарии обычно игнорируются компиляторами и интерпретаторами. Я не могу найти официальное заявление об этом эффекте специально для VBA (аналогично тому, как это делается для кода C в Visual Studio), но из экспериментального тестирования VBA, похоже, ведет себя так же.
Что касается количества кода в VBA, влияющего на производительность процедуры, очевидно, чем больше кода, тем больше времени потребуется процедуре для завершения выполнения.
Для большинства практических ситуаций это действительно не должно иметь никакого влияния.
Хорошо бы рассмотреть использование пробелов и комментариев не для производительности, а для удобства чтения.
VBA - это интерпретируемый язык, который означает, что интерпретатор должен анализировать весь ваш читаемый человеком код каждый раз, когда он выполняется, в отличие от скомпилированного языка, на котором читаемый человеком код один раз компилируется в машиночитаемый код. В обоих случаях пробелы и комментарии удаляются перед выполнением.
Теоретически, вы можете поместить в код VBA достаточно лишних пробелов и / или комментариев, чтобы в конечном итоге замедлить работу интерпретатора, но вам, вероятно, понадобится тысячи или 10 тысяч строк лишнего мусора, чтобы заметить разницу ,
Это сделало бы для интересного эксперимента, хотя!
