Запутывает, потому что действительно присутствует некоторая несуразность с отступами, вызванная тем, что году эдак в 2006м, когда процедура родилась, писалась она в редакторе с настройкой табулятора на 4 знака. За 12 лет процедура дописывалась и усложнялась раз 100 без преувеличений с разных компьютеров. Со временем для себя я уже ввел стандарт на настройку табулятора на 2 отступа. Но это появилось уже после. Часть кода Логпрог остается на старой системе табуляции. Ну нет у меня времени заниматься этой хренью и двигать пробелы среди тысячи строк, чтобы снова красиво было.
для Вас наверняка еще и непривычен мой стиль отступов. Это не недочет. Это выдержанный стиль.
For
 'код вложенный в блок всегда идет с одним отступом относительно шапки любого блока.
 next
Исключение
sub
end sub - на одной вертикали, потому что сгенерированы редактором автоматически. Не трогаю.
Второе исключение - блок then в конструкциях с  Else
If ... then
    'два отступа относительно if
 else' ,этот блок записывается с одним отступом от if
 end if - один отступ относительно if

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

А у меня нет привычки комментировать код вообще. Иной раз это плохо. Откроешь что-нибудь лет этак 5 назад написанное и сидишь вспоминаешь что за чем.

Код, который указан в #4 я бы записал так:

Скрытый текст

Код For B = C To D e = f     If e > 5 Then         g = a     Else         e = C         For h = 1 To 6             Select Case h             Case 1                 If B > 3 Then j = 2 Else: j = 22             Case 2                 j = 48             Case Else                 j = 54: Exit Sub 'принудительные выходы из блоков ставлю на тот уровень, на который будет выход.             End Select             If B > C + 3 Then j = 226: Exit For 'принудительный выход.         Next h     End If Next B

А что касается переменных, то тут зависит от того что пишу, но стараюсь не писать длинные, максимум буквы четыре.

По переменным. Как не напиши - без комментариев в общем-то они не особо информативны в серьезной программе.
А потому смысл их писать длинными? В описании переменных всегда не скуплюсь на комментарии. Это в обязательном порядке для каждой переменной.
К именам функций тот же подход. Функции в программе называются  aa,ab... az, ba..bz..ca... zz
Все переменные внутри подпрограмм начинаются с префикса имени подпрограммы и к нему приписан порядковый номер переменной. Лаконично.
Переменные уровня модуля вводятся путем объявления по названному принципу в той подпрограмме, где она первой потребовалась. Даллее в этой же подпрограмме закомментирую это объявление, приписываю global  и переношу его в заголовок модуля.

Не, не соглашусь. Нет однозначности в данном вопросе. И вот почему: Когда фрагмент кода прост и в нем кроме какой-то там максимальной строки других нет, то тут все банально и красиво с  lRowMax. Но стоит опуститься до каких-то сущностей типа последняя строка в блоке там-то там-то... и последняя строка в блоке вот здесь. И еще может в блоке соседнем. Или в блоке у дедушки... как тут выясняется, что   RowMax  - абсолютно теряет информативность. А за то префикс I, которым мы пытаемся отделить скажем lRowMax от URowMax - уже ничего путного не подсказывает. Я все-таки сторонник полного описания переменных в комментарии объявления переменной.  Потому что даже десятью символами в 50% случаев не заменить полноценного описания переменных в объемном листинге. Отсюда, тому, кто будет разбираться, по любому лезть за подсказкой к переменной придется.
Переменные пронумерованы сплошной нумерацией и найти каждую переменную в блоке их объявления - вообще не вопрос.
Поэтому активно пользуюсь разделителем окна кода на две горизонтальные области.

Видимо, Вы стиль_VBA.docx  вскользь просмотрели (или не открывали). Там о венгерской нотации написано. Только что проверил.

А тут есть что возразить?

Да,  есть. Уже возразил. Подобный стиль наименования переменных хорошь для демонстрационного кода в учебных целях. Когда берут какой-то маленький простой кусочек и показывают в нем какую-то маленькую особенность. Если же в алгоритме задействовано с десяток LastRow (а у меня практически всегда в процедурах довольно большой объем похожих сущностей переплетены во взаимодействии, то это LastRow превращается просто в бесструктурный балласт, загромождающий код. К тому же требующий еще и фантазии и потери времени на выдумывание названий. Да не дай бог забыть, что уже таким названием год назад пользовался, и не попытаться объявить его повторно... Короче, я за четкую структуру и логику. И эта структура должна быть и в именах. Словечки вместо структурированных именных переменных для меня вообще какой-то женский стиль. Нечто вроде Матиза на дороге.

Ну, кто такой Фэн-шуй? Всего лишь местный диалект Китая? А может быть и мода...
Вообще-то тема не про мой код, а для того, чтобы люди поделились своими вариантами. Фэн-шуй и без них известен и без этой темы. А тема про те правила, которыми пользуются программисты. Думаю, что у многих программистов есть свой собственный почерк и наработки, с которыми между прочим можно было бы и Фэн-Шуя познакомить!

А я вообще не понимаю откуда этот стиль как называть переменные. Это что ПУЭ или ГОСТ? По мне так как нравится так и называй. Всё равно в 99% никто в твой код не полезет и не будет править. А если и полезет править, то точно не человек, который ничего не понимает. Знающий уже по структуре и по командам поймёт что происходит. А если человек ни в зуб ногой, то тут как не обзывай он всё равно не поймёт что дальше происходит. Это уж тогда проще закоментировать.

Пока разговор в основном про Ваш )
Лично я Вашу позицию понял. Дальше неинтересно.

Соглашусь. Но пока единого стандарта нет и мы всегда будем вникать. Это хорошо бы было, если все пользовались какой-то определённой структурой имён и прочее, было бы гораздо проще. Практически тоже самое, что схему читать. Но пока что если разработчики дают такую возможность придумывать свои переменные, все и будут придумывать свои и подбивать под свою определенную иерархию и логику. У нас вот на работе тоже у каждого инженера своя методика маркировки элементов схем и проводов. Сколько лет пытаются привести к одному мнению, но у каждого своя изюминка. И когда уже долго работаешь с человеком и выучишь его методы, то оказывается всё довольно просто. Тут я думаю так же. Каждый программист притирается к своей команде и потом уже друг у дружки что-то заимствуют и получается нечто среднее, которое устраивает их команду. Но приди в другое место, скажут, что они ничего не понимают и начнут тебя переучивать делать по их законам и правилам.    

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

Кратко опишу, какие свои понятия(писаные и неписаные, признанные и не очень):
-переменной желательно задавать прфикс, означающий тип данных, который в ней хранится. Это избавит от постоянного перескока в декларации по Definition и выяснения что я там для неё написал. И это не прихоть, это опытом уже доказано.
-константы принято писать заглавными буквами. Это сразу дает понять, что это именно константа со своим постоянным значением. Я чуть расширил для себя это соглашение и для констант уровня модуля, проекта и процедуры у меня своя системы задания заглавных букв. В самих же константах часто применяю идентификаторы, которые дают понять к каких листам/данным/модулям константа имеет отношение.
-более менее осмысленное название для переменных, которые в принципе используются вне циклов и не один раз в коде. Например, если у нас идет цикл For Each и цель переменной цикла умирает вместе с окончанием цикла - то здесь можно обойтись заранее придуманными для себя односложными переменными:А вот lmax вполне осознанная переменная, которая может далее использоваться не один раз в коде. Она лишь получает значение максимального значения в цикле. Возможно даже не только в этом.
Если в один цикл вложены еще циклы - здесь я лично действую по ситуации. Если внутри идут конструкции с перекрестным использованием переменных всех циклов, то я даю имена так, чтобы сразу было ясно к какому именно циклу относится переменная. Простой пример(очень простой для раскрытия сути) - перебор строк и столбцов в массиве:-имена процедур и функций тоже должны иметь внятные названия, по которым будет сразу понятно что делает функция/процедура и какие значения может возвращать. Так же при написании функций с параметрами желательно переносить объявление параметров на строки так, чтобы все параметры были видны на экране без прокруток. Это избавить от лишних телодвижений, если придется разбирать функцию. И вот как раз для функций может быть весьма желательным описание в заголовке того, как она работает(общий смысл и зачем тот или иной параметр). Если забросить проект месяца на три - это поможет не сильно долго вспоминать что и для чего.
Понятно, что помимо этого есть и отступы кодов, есть разделение на модули по функционалу или применению и т.п.

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

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