В середине 00х, еще до выхода 1С8.1 не существовало никаких стандартов написания кода на 1С. В то время я пришел на работу в один из ТОП-5 киевских франчей (потом станет ТОП-3), а курсы по программированию для джунов читали партнеры, тоже из киевского ТОП-5. И уже на вводном занятии, где нам показывали условный "Hello, World", я сразу задал вопрос - а как нужно правильно называть метаданные и переменные? Это очень важно с учетом отсутствия строгой типизации (как в JavaScript и прочих интерпретируемых языках). Мне ответили, что никаких общих стандартов не существует и могу называть как хочу.
Прошли годы и стандарты стали появляться. Как я понимаю, локомотивом перемен стала команда разработки БСП (общая библиотека большинства типовых конфигураций от 1С), которые свои наработки стали публиковать как "промышленный стандарт".
Когда в других языках есть "промышленный стандарт" для написания кода, то сначала учат его, на соответствие ему настраивают Sonar и лишь потом пишут код - пример, PEP8 для Python. Но "промышленный стандарт" от 1С почему-то многими игнорируется, а еще больше специалистов вообще про него не знают. Почему так сложилось?
Я вижу две причины, по которым стандарты не прижились -
слишком поздно появились и
оторваны от жизни. Очевидно, что если есть технология и тысячи клиентов, то никто десятилетиями не будет ждать подарок от братьев Нуралиевых и все давно сами выработали для себя внутренние стандарты хорошего кода. По сути "промышленный стандарт" - это просто правила для прохождения аудита от 1С для добавления в каталог решений. Не уверен, но думаю, что именно эти же правила использует команда Инфостарта для добавления в собственный магазин решений.
Почему стандарты оторванными от жизни? Потому, что они пишутся под БСП, которая пытается эмулировать ООП на базе DSL (язык для автоматизации предметной области).
Берем
правило разметки областей модуля, согласно которому EDT самостоятельно вставляет в новые общие модули области - Public, Internal и Private. Но ведь это калька подхода из языков, у которых есть наследование, которого у 1С нет. Зачем нужна область Internal, в которой описывать экспортные методы и функции, которые декларативно запрещено использовать всем потребителям кроме других модулей подсистемы?
К слову, некоторые служебные экспортные функции БСП так и хочется использовать, так как они удобнее чем "публичные". Помню, что при рефакторинге стандартной подсистемы на партнерском форуме всегда было много возмущений - зачем вы нам все поломали? Ответ от разработчиков - а зачем вы использовали служебные экспортные функции, которые по стандарту только мы имеем право их использовать! Получается, что стандарты, которые теоретически направлены на облегчение восприятия и легкость поддержки кода, наоборот поощряют делать запутанный, тяжело анализируемый и плохо поддерживаемый код.
Я считаю, что
в случае общих модулей, которые технически невозможно наследовать и переопределять,
имеют смысл только два типа методов - открытые и закрытые! Не должно быть удобных экспортных функций для "избранных" и неудобных медленных вариантов для "простых смертных". Архитектурно нужно закладывать, что все экспортные методы должны быть открытыми, а все служебные функции не должны вообще иметь свойства "экспорт". Простое правило и внезапно уже нет нужды в десятке "подмодулей", которые дублируют методы; и код становится в целом чище и понятнее!