(5) Да для тех у кого есть действующая подписка на ИТС документ называется
Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8
(6) Мне это известно. Подраздел "Соглашения при написании кода".
Но:
1. Он закрыт от общего доступа, соответственно нельзя просто взять и дать ссылку человеку.
2. Он проприетарный, а не community-driven. (для примера в написании ruby style guide принимали участие 145 человек, python style guide 297 человек).
Из "Чистого кода" Роберта Мартина: "Параметр функции не должен возвращать значение".
К сожалению, 1С этим часто грешит даже на уровне платформы, из-за чего появляются уродцы типа
Значение = Неопределено;
Если Структура.Свойство(Ключ, Значение) Тогда
Сообщить(Значение);
КонецЕсли;
Также добавил про имена переменных и методов, содержащих отрицание, например "НеЗначениеЗаполнено", "НеСоответствует" и т.д. рано или поздно, так или иначе к этой переменной/методу добавится условие "Если Не НеЗначениеЗаполнено Тогда"
При доработках конфигурации не называть добавляемые общие модули "Вектор5_ОбщегоНазначения" или "ВасяПупкин_ОбщегоНазначения". Сопровождающий франчайзи может смениться (да-да, к вам это тоже относится), и перед преемником встанет задача или глобального переименования вызовов, или создания своих модулей - а это уже может привести к плодотворной работе по изобретению велосипедов.
Лучше назвать
хх_ОбработчикиПодписокНаСобытия
хх_ПрочиеФункцииСервер
хх_ПрочиеФункцииКлиент и т.д.,
где хх - аббревиатура заказчика.
Законодателем стайлгайда и де юре и де факто может выступать только 1С, документируя его и применяя в своих типовых. Хорошо это или плохо - вопрос к теме не относящийся. Отсутствие открытого - не аргумент. 1С проприетарна с головы до ног, вообще-то.
Поэтому советую сразу скорректировать направление "полета": противоречий с "линеей партии" быть не должно. Да и вообще лучше один неидеальный стайлгайд, чем два разных.
Законодателем стайлгайда и де юре и де факто может выступать только 1С
В корне не верно. 1С может только рекомендовать. Требовать они могут только на экзаменах, либо при сертификации решения на 1С-Совместимо...
Законодателем стиля разработки де факто выступает рп/ тим-лид конкретной команды разработки, либо заказчика. Да и то, только в том случае, если в команде/ проекте используют соглашения по написанию кода, формированию имен переменных и т.п.
С этим полностью согласен. Система стандартов - всегда должна быть основой, а конкретные моменты, такие как порядок формирования префиксов, формирование имен переменных, порядок именования общих модулей и т.п. должны дополнять/ заменять соответствующие разделы в "Стандартах"...
Ну а всякие дополнения и полезные советы, ессно, приветствуются.
Только предлагаю сразу разделить на две категории: по стилю оформления и по стилю программирования.
Подписка есть, поэтому нырнула в этот раздел, воспользовавшись пословицей: "Повторенье - мать ученья". Использую много из вышеперечисленного. Правда в качестве префикса использую аббревиатуру привлеченного нами разработчика, добавляя там, где правила и дописывала уже сама свою.
Законодателем стиля разработки де факто выступает рп/ тим-лид конкретной команды разработки, либо заказчика. Да и то, только в том случае, если в команде/ проекте используют соглашения по написанию кода, формированию имен переменных и т.п.
Полностью согласен, это начинание и задумывалось как основа для соглашений, используемых в команде, основанных на наработанном сообществом опыте.
Любой тим-лид/тех. архитектор/пм и т.д. может взять за основу данный документ, дополнить/удалить нужное и использовать.
В идеале по этим правилам бы еще статический анализатор разработать, который можно было бы использовать в CI на данном этапе и в iDE впоследствии.
За начинание - Плюс в "карму".
Мне кажется имеют право на жизнь два подхода :
1- от 1С - и франчи обязаны его использовать.
2- оговоренный для команды в рамках продукта. Мало того- соглашение по стилю кодирования и оформлению кода должно быть составной частью "Устава Продукта". И базироваться он должен на Системе стандартов и методик разработки конфигураций для платформы от 1С.
Когда в рамках холдинга несколько заказчиков разрабатываемого функционала - то могут возникнуть трения и недовольство данным подходом.
Тогда и не будет возникать вопросов по подходу и трений.
(19) есть стандарт - не более 120 символов.
В создаваемых конструктором запросах это лень соблюдать (да, наверное, и незачем), а в коде стараюсь ограничивать.
Жалко, что в конфигураторе 1с нельзя сделать красную полосу ограничения.