Страницы: 1
RSS
Общие вопросы создания кода VBA
 
При знакомстве с VBA возникают небольшие "блохи", отдельные темы для которых - роскошь.  
Если где-то есть явные ответы, отсылайте туда.  
   
1. Оформление кода.  
Красиво и читаемо смотрится код с отступами. Есть же какие-то стандарты на оформление, ведь спец. программы могут расставлять отступы автоматически? Где об этом почерпнуть информацию?  
 
2. Разделение кода.  
Например, в форме записана процедура, часть которой - обработка листа. Можно прописать все в одном макросе, а можно выделить часть, касающуюся листа, в отдельный макрос и поместить в общий модуль. Оправдано ли и как влияет на работу такое разделение?  
 
3. Объявление переменных типа Public.  
В одном из модулей, потому что все на виду. Там, где больше используются. А если переменная используется кодами общих модулей, листов и форм? Т.е. из практики - где лучше размещать Public ... As ...?  
 
4. Одна переменная для разных действий. Оправдано ли?  
В разных процедурах переменная Dim n. Понятно, что отработка одной процедуры никак не влияет на работу следующего макроса с такой же переменной. Но вопрос по открытым переменным. Например, при открытии книги производятся действия с последней строкой одного листа, далее с последней строкой другого листа. Можно использовать две переменные, но можно только одну Public RwsCnt -экономия памяти. Что скажут практики?
 
Привет, Вить.  
1) Да есть программа 263 кб в раре(IndenterVBA.rar), могу кинуть в личку. Но поищи, на форуме уже выкладывали.  
2) Оправдано. на работу особо не влияет, но улучшает читаемость кода.  
3) Всегда размещай в общем модуле, тогда будет видна из всех модулей.  
4) Очень оправдано, экономим память. Например счетчик i можно использовать во всех циклах модуля, если они не вложены друг в друга.
Я сам - дурнее всякого примера! ...
 
vikttur, Вы как то пропустили тему, где писали кто что использует. Поискать надо, ссылку не сохранил.  
использую, по совету старших товарищей, MZTools - просто хорошая утилитка (добаление названий процедур, копирование контролов и пр.),IndenterVBA - отступы.  
2 а примеры от ZVI посмотрите. У него стандартные действия вынесены в функции или приватные процедуры с параметрами и просто обращаемся к ним когда надо. Да и вообще многие решения ZVI можно просто вставлять как часть решения:)  
3. Объявление переменных типа Public - в общем модуле. тогда они доступны из любой части проекта. (форма, модуль листа)  
4. можно запутаться, и так, как опыта мало можно получить ошибку или не ожидаемый результат по незнанию.  
Все выше сказанное только ИМХО, основанное на небольшом личном опыте.
 
1) http://excelvba.ru/soft/VBE  
 
2) На работу никак не влияет. Дело вкуса.  
 
3) Чем меньше таких переменных - тем лучше (не запутаетесь).  
Я стараюсь передавать такие переменные в другие процедуры в качестве параметров.  
 
4) Если мне надо сделать несколько макросов, в каждом из которых есть цикл, - в каждом из макросов я использую одну и ту же переменную i  
Поскольку видимость переменной ограничивается текущей процедурой, проблем не возникает.
 
Спасибо.  
1. Дружно не поняли. Я спрашивал не о программе, а о стандартах или правилах написания кода.  
3. Сам плохо объяснил. Что лучше - все  Public в одном общем модуле или размещены в разных общих модулях?
 
1. Стандартов НЕТ.  
Каждый оформляет код так, как ему удобнее.  
 
Есть что-то вроде общепринятого формата кода - это можно увидеть, применив программу IndenterVBA с настройками по умолчанию.  
 
3. Лучше - в одном модуле, ИМХО.  
Ещё лучше - вообще не использовать такие объявления переменных.  
 
В моих проектах (даже очень сложных) число глобальных переменных обычно равно 1 + число строк кода, делённое на 500.  
Т.е. в макросах до 500 строк кода обычно бывает максимум 1-2 глобальных переменных.
 
В моем четвертом ответе вместо модуля, я хотел сказать макрос. Никогда не упускаю возможности повторного использования переменных в макросе. Но, при этом нужно быть очень внимательным. И в таких случаях оператор Goto уж точно недопустим.
Я сам - дурнее всякого примера! ...
 
1. Всегда оформляй табулятором отступы тех блоков, которые имеют "начало" и "окончание": For-Next, If-End if, With-End With... Вложения внутри них - аналогично.  
2. Иногда делаю разделение - может потребоваться вызов "разделённого" из другой процедуры. А тут и писать заново не нужно.  
3. Если гарантированно всё в одном модуле (форма, лист), то можно внутри. Если есть подозрение, что может потребоваться и в других - выноси сразу в стандартный модуль.  
4. Часто стал использовать (писать меньше :=)
 
{quote}{login=EducatedFool}{post}Ещё лучше - вообще не использовать такие объявления переменных. В моих проектах (даже очень сложных) число глобальных переменных обычно равно 1 + число строк кода, делённое на 500.  
Т.е. в макросах до 500 строк кода обычно бывает максимум 1-2 глобальных переменных.{/post}{/quote}  
В моем не очень сложном проекте таких 9 шт. Есть куда расти :)  
Чем плохи глобальные переменные, кроме аппетита?
 
Выводы для себя.  
1. Стандартов нет, но ведь программы под это как-то пишутся? О табуляторе и не думал, пробелы вводил :)  
2. Делить на стандартные, законченные процедуры. На работу не влияет.  
3. В один модуль. Не услышал, чем плохи глобальные переменные. Пока с ними легче. Например, перменная введенного пароля используется в разных процедурах разных форм. Как вариант, можно записывать в ячейку. Но не думаю, что такой вариант лучше.  
4. Такое мнение было и до этого - внутри процедур не страшно, можно отследить, с глобальными лучше перестраховаться.  
Всем спасибо за науку.
 
добавлю пять копеек :)  
 
стандарты кода появляются при большом объеме программ - vba на это не тянет. Более того, некоторые стандарты к нему неприменимы. Так как это интерперетируемый язык, то и код несколько отличается. в общем случае:  
 
1. отступы - использую табулятор(tab/shift+tab) - большего и не надо  
2. повторяющиеся фрагменты оформлять процедурами/функциями.  
3. public переменные объявлять только в тех случаях, если это действительно необходимо.  
4. переменные называть мнемонически значимо, использовать соответственно. Допустимо использование переменных счетчиков цикла в разных циклах.  
 
для vba:  
 
1 -"-  
2 оформлять, но если подпирает время, то это первый кандидат на распределение(берем на себя функции компилятора)  
3 объявлять. Лучше в отдельном модуле - легче освежать в памяти, не создавая закладок..  
4 можно использовать для разных действий с учетом совпадения типов и частоты обращения.
Живи и дай жить..
 
Спасибо за мелочь :)
 
Во многих учебниках авторы рекомендуют:  
"Чтобы избежать неверного ввода имени переменной или риска конфликтов имён в программе используйте инструкцию Option Explicit, обнаруживающую опечатки в именах  
переменных на стадии компиляции (до выполнения программы)."  
Лучше позволить VBA выругаться, сказать что он о Вас думает, но избежать большого скандала во_время_работы.  
 
Для установки 'Option Explicit' в проекты по умолчанию:  
в редакторе VBA установить флажок 'Require Variable Declare' на вкладке 'Editor' диалога 'Tools'->'Options...' .
 
это да, эт прально!
Живи и дай жить..
 
{quote}{login=слэн}{date=06.12.2010 09:56}{thema=}{post}  
стандарты кода появляются при большом объеме программ - vba на это не тянет. {/post}{/quote}  
 
количество программ на vba просто огромно, не говоря о vb.
 
хорошо, разверну свою мысль :  
 
при таком объеме программ(мы), когда индивидуальное ее создание становится неэффективным. Колеегиальное творчество начинает требовать упорядочивания - стандартов.  
 
так согласны? :)
Живи и дай жить..
 
Вот когда начнут в VBA стратегии с трехмерной графикой рисовать, тогда уж без коллектива никак. Придется стандарты писать. Если что, в стрелялках, в укромном уголке, где авторы, прошу помечать "автор мысли о стандартизации vikttur" :)  
 
А Option Explicit давно уже с птичкой.
 
>>> vikttur: 4. Одна переменная для разных действий. Оправдано ли?  
>> KukLP: Очень оправдано, экономим память. Например счетчик i можно использовать во всех циклах модуля, если они не вложены друг в друга.  
 
Я, вообще, последнее время "грешить" чем стал - использую переменную не только в цикле (как счетчик), но и внутри него  
 
Sub io()  
Dim x ' Variant  
   For Each x In Sheets ' Object  
       x = x.UsedRange.Value ' Variant - массив (если не пустой лист)  
   Next ' А здесь все равно x примет следующий элемент коллекции, и станет опять Object  
End With
Чебурашка стал символом олимпийских игр. А чего достиг ты?
Тишина - самый громкий звук


https://github.com/nervgh
 
2 nerv  
С Вами все понятно, Вы то знаете что делаете:)  
Но вот когда пишешь на форум - лучше все в отдельности:) Ведь на форуме большей частью учатся и не понимают нюансов. А потом в своих проектах будут удивляться неожиданному/ не расчетному выполнению программы.
 
{quote}{login=nerv}{date=15.10.2011 10:44}{thema=}{post} все равно x примет следующий элемент коллекции, и станет опять Object{/post}{/quote}Но следует учитывать, что Excel требуется время для определения типа. В данном случае я бы использовал две переменных с разными типами.    
Согласен с Игорем: на Форум - особенно.
 
>>Но следует учитывать, что Excel требуется время для определения типа. В данном случае я бы использовал две переменных с разными типами.  
 
Ок, Такой пример:  
 
Sub io()  
Dim x As Object  
For Each x In Sheets  
Set x = x.UsedRange ' Думаю, тут время на определение типа не требуется, а размножать переменные, не всегда гуд. Хотя и Игорь, и Юрий, разумеется, правы.  
Next  
End sub
Чебурашка стал символом олимпийских игр. А чего достиг ты?
Тишина - самый громкий звук


https://github.com/nervgh
 
Саня, слушай старших. Даже для тебя такой подход чреват граблями, а если с ним придется работать другим? Ну сэкономил ты 12 байт(а верней совсем не сэкономил, экс все равно создаст два экземпляра переменных в памяти), стоит оно граблей?
Я сам - дурнее всякого примера! ...
Страницы: 1
Читают тему
Наверх