На форуме много примеров. Там и можно посмотреть, у кого какой почерк )

У меня.
Венгерская нотация.
Имена переменных и процедур - более-менее понятные (не f25, jjj)
Массивы - с буквы a (aSpl, aNameFiles())
Переменные, применяемые часто - имена не меняются и короткие (lRw, lClmn, sTmp, bFlag, dDateS)
Глобальные переменные - применяю, но стараюсь обходиться без них.
Cчетчики - одна буква: i,n,m - по вертикали, j,p ("с хвостиком") - горизонталь
Объявление переменных и наличие Option Explicit - обязательно
Использование событий листа - по необходимости, но если можно обойтись, заменяются другим.
Обязательное включение отключенных обновления экрана, сообщений... Обязательная очистка ранее занятой памяти (Set wBook = Nothing)

Отступы в коде - обязательно.
Объединение строк в одну, через : - если строки логически связаны и не длинно. Или, например:
If a<b Then a=b (одной строкой, без End If)
Раньше писалось все в одной процедуре-простыне, сейчас разделяю на отдельные процедуры и функции.

Это навскидку, что быстро вспомнилось.

Не думаю что стоит беспокоится на счет стиля VBA - прикладной язык для частных задач, здесь главное не красота разработки, а ее скорость. Часто приходится что-то переделывать под вновь открывающиеся обстоятельства. В этом собственно и плюс. Пока системный программист только составит план, ты уже сдаешь проект. 80% проектов можно написать объектами книги, листа, а уже  что-то, где требуется реальное быстродействие - работа с очень большими данными или частое применение макросов, здесь стоит подключить массивы, словари, коллекции и т.п.

По мне, главная ценность прикладного программиста умение быстро видеть и закрывать потребности в автоматизации и закрывать их по возможности на 100%. Видел много красивых кодов, но они решали 5% всей задачи, тогда как ее можно было решить кодом на 100%. Здесь и неумение пользователей ставить ТЗ и нежелание разработчика разобраться в процессе.

Также видел много "красивых" с точки зрения тех кто учился на программиста кодов - все объекты завернуты в переменные, каждая мелочь выносится в функцию, повсюду метки GO TO (типа обработчики ошибок) - разобраться в таком коде сопровождающему непросто и не быстро. VBA это скрипт - когда ты считываешь понятную последовательность операций со знакомыми объектами поддержка чужого кода становится куда проще. Я не говорю что надо писать все в одну портянку, но излишние объявления и заворачивания тоже зло. Также и со стороны разработки - человек пишущий знакомыми методами и шаблонами, просто соединяя их как конструктор и меняя параметры может закрыть задачу за день, между тем как любитель написать красивый код берет на нее неделю.

VBA программист это не просто кодер – зачастую он сам себе и архитектор и бизнес-аналитик и проектировщик.

Написанию программ на VBA учился самостоятельно, так что многое приходилось осознавать через грабли.
Самый главный вывод, изучите все возможности Excel, в частности функции, условное форматирование, сводные таблицы, Power Pivot и Power Query. ИМХО 95% всех задач в Excel можно решать собственными средствами Excel не прибегая к кодированию.

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

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

Сужу чисто из своей практики:

1. Оформление каждой подзадачи в процедуру облегчает чтение кода;
   
2. В большинстве случаев нельзя заранее предугадать какую именно подзадачу придётся использовать повторно;
   
3. Даже если оформленная в отдельную процедуру подзадача больше не пригодилась в коде, она может пригодиться в другом проекте, так что её можно будет просто скопировать в готовом виде, без шелухи.
   

Речь не об обычных пользователях а именно тех, кто решил кодить в VBA. Так как, например использование условного форматирования, может гораздо облегчить процесс оформления "юзер-интерфейса" при создании приложения, а использование расширенного фильтра облегчит труд по написанию кода для выгрузки данных по условию. Именно поэтому, человеку решившему кодить на VBA для Excel полезно для начала изучить весь функционал этой программы.

А есть такие, которые знают весь функционал? )

Ключевое слово "Полезно", а не "Обязательно"

Соглашусь, пусть будет не ВЕСЬ. Но Уокенбаха хотя бы почитать стоит.

Напишите книжку "Продвинутые методы программирования на VBA". Для тех, кто пришел не из программистов. Про массивы, словари, коллекции, FSO, ADO, соединения с БД, работа по расписанию и т.п. Все что реально может вывести офисную работу на новый уровень - скоростные/лаконичные обработки. С подробным объяснением кодов. Думаю спрос будет - я бы точно купил. У того же Уокенбаха многое оторвано от жизни, да и тяжело читать книгу в 900 страниц, в которой напичкано всего.