Как считаете стоит ли приписывать префиксы к добавляемым объектам конфигурации при использовании БСП и почему? Имею ввиду при разработке конфигурации с нуля для продакшена.
Например объект метаданных конфигурации заводить с именем "мистаСписокПользователей" или стоит писать все таки "СписокПользователей"
Просто будут наименования и с префиксами и без, по рекомендациям их нет https://its.1c.ru/db/v8std#content:550:hdoc
Так зачем многие отраслевки их используют? Боятся не различить функционал из БСП и добавленный?

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

(0) Вкусовщина.
БСП отчленяется отбором по подсистемам.
Другое дело когда коробка на базе решения, а не БСП, там с префиксами попроще как то

(2) Ибо рано или поздно в существующую подсистему что то да воткнуть придется.

(2) Да есть "СтандартныеПодсистемы", чтобы отбор сделать.
Только я вижу решения на базе БСП с использованием префиксов (((

(0) я б за префиксы б пиз*дил палкой. Но иногда без них хуже, чем с ними. Общее правило: не использовать префиксы. Но фанатизм свойственен только фанатикам, а профессионалы умеют находить баланс.

И подсистему свою и префиксы. На одном месте префикс включал номер ТЗ и ничего, нормально было.

Если самописка на базе БСП, то можно и без префиксов

Если это доработка уже какой-то имеющейся конфы, то префиксы или суффиксы

префиксы - это лепота, альфа-авто не даст соврать )))
дкДокументы
фзФоновыеЗадания и т.п.

(5) +1

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

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

Не совсем понял вопрос. Если новая конфа с голой бсп, то, конечно, префиксы в топку. Просто по важности темы выглядит так, будто вопрос о префиксах при доработке в типовой конфе.

хм. ладно когда клюшки, где всех объектов метаданных в типовой конфигурации штук 50-100, еще это все можно упомнить/знать.
.
а когда крнфига где обьектов метаданных под несколько сотен?
.
хреняк какой-нить
Справочник.ТипыКлиентов - это вообще штатный или дописанный..?

(14) так вроде речь про БСП
там даже понятия такого как клиенты нет вроде бы особо

(14) (15) в первом предложении ясно написал вроде, что использовать ли префиксы "при разработке конфигурации с нуля с использованием БСП"

"к добавляемым объектам конфигурации при использовании БСП"
-то есть спецы по 8-ке настолько сильные колдунствы, что глядя на наименование обьекта конфигурации и не видя окружения этого обьекта - могут сказать что это или стандартный обьект БСП или добавленный?!

(17) Ты не поверишь, но в 8.х если конфигурация поставщика на поддержке, а БСП должна быть на поддержке, то таки видно типовой это объект или нет. Это касается не только объектов метаданных, но и их реквизитов и объектов объектов. :)

(0) Видел решение где была не совсем типовая БП, потом сверху расширение Бит-Аренда, потом ещё одно расширение... и тут меня позвали дописать функционала... добавил префиксов у новых объектов - а что делать! Тот кто будет после меня допиливать и так будет нервничать

Нет, префиксы в программировании это изживший себя атавизм. Когда IDE ещё не было, венгерская нотация облегчала жизнь. С появлением IDE венгерская нотация изжила себя. И вот, каким-то чудом, в 21-м веке, кастрированная венгерская нотация в виде префиксов к объектам, умудрилась воскреснуть в 1сной отрасли...

(6) "На одном месте префикс включал номер ТЗ и ничего, нормально было"

За такое нужно руки отрывать. Комментарий к объектам метаданных для слабаков?

(14) если до конфы не добрался рукожоп и не снял все объекты с поддержки, то значок напротив объекта метаданных всегда подскажет, типовой он или нет

по мне надо находить баланс как то, вот в клюшках было все просто, все что в глобальнике бало с прификсом "Гл", в снеговиках это уже больше путает, так что хз

(17) По желтому кубику определяется. Не в проде, конечно - там конфы поставщика быть не должно.

(23) почему не должно?

2. Не использовать префиксы
надо использовать "Комментарий"

Если на базе чего-то разрабатываешь, то префиксы возможны. Особенно для похожих процедур. Но без фанатизма. Т.к. наличие замочков помогает понять что к чему.Например, в расширениях они явно рекомендованы на уровне платформы.

(0) Префиксы - это удобно. Удобно - значит быстрее. Быстрее - значит эффективнее. Эффективнее - значит больше денег. Вывод: Префиксы - к деньгам.

(14) должная быть своя подсистема, куда входят все новые объекты
(0) отраслевые частенько выходят не только как самостоятельные решения, но и как модули к ERP, там то префиксы и пригодятся

(24) Лишние хлопоты. Если конечно у тебя есть еще как минимум два, а лучше три контура.

Префиксы как универсальное решение можно использовать когда в конфе есть и "стандартные" объекты и добавленные разработчиком.
Префиксы также можно использовать для разработческих реквизитов добавленных в стандартный объект.
Немного пострадает автонабор текста кода, но будет существенный выигрыш в уникальности, разделяемости и определяемости объектов\реквизитов.
Также можно использовать префиксы в названиях переменных\параметров, например, для определения типизации или для отделения их от других свойств с похожим наименованием.

+ префиксы улучшают ситуацию с переносимостью кода в другие конфигурации, главное чтобы они были нейтральными, т.е. без номеров заявок, ФИО и т.п.

(30) "использовать префиксы в названиях переменных\параметров, например, для определения типизации" // Ни одного оправдания этому быть не может

+ само собой для добавленного функционала надо создать отдельную подсистему.
еще бывает в синонимы некое представление подсистемы добавляю, чтобы пользователи могли отличать типовое от нетипового

(0) Имхо нужны не префиксы а поддержка разделения метаданных через "."
Для разных подсистем, расширений, поставок и т.д. можно задать свой префикс и хреначить такие же названия метаданных.

Обращаться через моя_подсистема.МойСправочник и т.д.
По умолчанию если префикс не указан но последовательность поиска в платформе, сначала основная конфа/поставка, потом дополнительные поставки, потом подсистемы и расширения.

Если одно название и кто то скосячил да будет упс - решать через платформу чтобы ошибки/неопределенности подобные выводила при проверке.

(32) если разработка ведется под полным контролем архитектора или разработчик один - то да, можно обойтись.
как собственно 1С и поступает.

когда мам и пап множество, то можно наколоться с совпадением названий параметров\переменных и цена такой ошибки может быть высока для бизнеса.
а так как-то с семерки довольно удобно определять и случайно не перепутать например тип переменной, так как типизация в 1С неявная, к сожалению.

(34)+ А потом останется добавить алиасы это когда разраб может переобозвать подсистему или расширение как ему надо и использовать свое это новое название.

И будет почти как в C++ гы

(32) а в чем недостаток префиксов у переменных ? то что автонабор не работает ? и все ?

(35) "можно наколоться с совпадением названий параметров\переменных" // Приведт пример

(35) Строгая типизация нужна чтобы не перепутать!

А то иш псевдотипизацию через префиксы придумали

(37) Усложнение изменения кода (рефакторинг или доработка), в результате которого тип переменной приходится поменять

Ну и почти всегда - ухудшение читаемости из-за всяких этих "б", "мс", "тз" и прочее

(40) ИМХО наоборот рефакторинг станет понятнее\надежнее. А замену легко сделать и пакетно. Главное чтобы переменная существовала в контексте функции\процедуры и только, как и правильно в общем-то.

"Главное чтобы переменная существовала в контексте функции\процедуры и только, как и правильно в общем-то" // А как же передавать параметры в методы? У тебя метод-то один, а точек вызова - дохера. И в каждой у тебя будет написано ВызываемМойМетод(мсМойМассив);
А потом хоба - ты решил тип параметра изменить.

(41) префикс должен быть в нижнем регистре, тогда он со временем "игнорится" мозгом, а когда надо "воспринимается".
мне привычны варианты и с и без - не вызывает проблем, наверное привычка

(43) временами стал уходить от передачи нескольких параметров в сторону передачи структуры параметров,
тогда вопрос с рефакторингом на точках входа автоматически решается.
предвижу следующий вопрос :))

(45) + так кстати иногда поступает сама 1С при передаче параметров в типовые конструкции - значит и мне можно :)

(45) Ну так структуру-то ты в точке вызова все равно инициализируешь, т.е. заводишь под ее значения переменные

(38) навскидку реквизит формы может совпасть

(39) так ее ж не дали! я б с удовольствием... и иногда когда никто не видит раз в пятилетку этой фичей можно воспользоваться ;)

(46) так это и в стандарте есть, но с оговорками - структура должна не один элемент содержать, а несколько.

(48) Если ты добавляешь реквизит в форму, то присваиваешь ему префикс по подсистеме. Таким образом совпасть он с уже имеющейся в модуле форме переменной никак не сможет.
А если наоборот - ты добавляешь в модуль формы переменную, совпадающую с уже имеющимся реквизитом формы, то сам виноват - смотреть надо. Добавляя префикс _типа_ к имени переменной ты по сути снимаешь с себя бремя необходимости такого контроля и вместе с тем почти наверняка снижаешь сопровождаемость кода.

(50) меня эта тема СИЛЬНО выручает когда разработка без четкого ТЗ и изменения надо вносить ОПЕРАТИВНО

(47) необязательно

(53) ?

(51) как раз префиксы к реквизитам формы добавлять я против - почему-то так сложилось - может с сортировкой связано по представлению.

"
ты добавляешь в модуль формы переменную, совпадающую с уже имеющимся реквизитом формы, то сам виноват - смотреть надо
"

не все могут в будущее заглянуть, когда неясно кто как и когда что добавит в конфигурацию.
типовые вообще постоянно переписываются и я им на слово должен верить что они не задублят мои названия ?
я ведь могу и в типовой код добавить свой

(55) + я же говорю - если архитектор\разработчик один и так будет ВЕЧНО - можно не париться

Структура в параметрах это тоже отдельный вид зла. Должна быть крайним средством

(57) ну мы же в адинэсе - тут не существует идеальных решений :)

(58) + в семерке еще были глобальные переменные - тоже отдельный вид зла

(54) ну надо от конкретной ситуации идти... иногда это простые типы данных, которые врядли поменяют тип (при проектировании это обдумывается), иногда это таблица значений, которая собирается из простых типов и т.п.
Вместо соответствий, массивов лучше использовать ТЗ сразу как универсальную коллекцию. Это как бы хитрости которые приходят со временем в "гибкой" разработке. Никому не навязываю подходы естественно :)

(51)
"Добавляя префикс _типа_ к имени переменной ты по сути снимаешь с себя бремя необходимости такого контроля и вместе с тем почти наверняка снижаешь сопровождаемость кода."

Речь веду про конфигурации которые врядли выйдут в коммерческую серию. А раз так то это разработка под конкретный бизнес, а бизнесу первично 24/7 стабильная работа, а то что разработчики страдают - это для бизнеса вторично.
Если случится так что попаду в коммерческую разработку и даже о боже! в саму 1С, естественно подход изменится в соответствии со стандартами данной конторы, но тогда я рассчитываю что в конторе будет человек (а может и я) который отвечает за архитектуру решения :)

Префиксы для новых метаданных и реквизитов, добавленных в старые метаданные - в основном да. Прочие префиксы (особенно все эти тз, сз, м, стр к переменным) - в топку

(61) А при чем тут какая-то "коммерческая версия". Сопровождаемость - это про любые изменения в коде и работу с ним человека. По неважно каким причинам.

Кажется мне что префиксы переменных меньшее зло, чем неинформативные, сокращенные, короткие или наоборот огромные по длине названия.
2-3 коротких слова норм как считаете ?

(63) притом что жопа разработчика у коммерсов рядом, а им как я говорил важна стабильность а на эстетику которую только мы понимаем им пох.
а вот если ты разработчик отраслевки или сама одинэз который анально огорожен от потребителя, там можно поэстетствовать в свою пользу.
так понятнее ? :))

(65) Никогда не знаешь, когда придется лезть в свой же код - так понятнее?

(65) + у всех опыт разный, где-то можно оступиться без последствий, а где-то ошибка с из-за совпадения названий - это потери в несколько лямов и репутация. лучше бы 1С действительно сделал обращение к сущностям всегда через точку чтобы избежать неоднозначности.

(66) у меня не вызывает отторжения влезть (и при необходимости переписать) в любой код, кроме неотформатированного, но это дело трех секунд его форматнуть :) Ты преувеличиваешь сложность поддержки из-за префиксов, правда. Гораздо сложнее по сравнению с префиксами работать с запутанным кодом с многократно вложенными вызовами функций или с собираемыми запросами. ИМХО сложность с префиксами может быть из-за ошибок на этапе проектирования или с физическим неприятием их.

"Гораздо сложнее .. работать с"
Зачем ты ругаешь 1с?

(68) "Ты преувеличиваешь сложность поддержки из-за префиксов, правда" // А где я говорил о какой-то сложности? Я говорил о ее увеличении.

(67) Ну да, тут не спорю - обращение к реквизитам формы должно быть через спец. коллекцию (как, например, Параметры)

(69) да нее... как можно пойтить против матери-кормящей тя :))
если бы у них было все идеально - не было бы тех кто держит ее под руки и костылик подает.

(62) надо наоборот:
- в реквизитах без префикса
- в переменных с префиксами СЗ, ТЗ и др. т.к. стандарт венгерская нотация

Свои доделки всегда подписываю префиксами, уже вошло в привычку. (префикс в 2-3 буквы, примерно так: цуСправочник или цукСправочник) Не желательно между префиксом и названием использовать нижнее подчеркивание, был случай когда в запросе не срабатывали названия с нижним подчеркиванием.
В коде Процедуры и Функции тоже с префиксами пишу.
Также при изменениях в стоковом коде обозначаю начало и конец переделок, а основной код при этом "коменчу".
Тебе понятно и другие скажут спасибо.
--------------------------------------
Что-то пипа такого:
//-> ФИО дата
//основной код
мой код
//<- ФИО дата

(73) Какой стандарт? Я в основном в стандарты вендора смотрю. А про переменные он говорит следующее:

https://its.1c.ru/db/v8std#content:454:hdoc

Все эти сз, тз - указаны как пример некорректного именования

(75)
Согласно стандарту переменные могут быть:
На, По, Под, Над, Не, Или, Это, То.

(76) Ну, если "на" или "по" образуется из терминов предметной области, то наверное да

Если предполагается какой-нить РИБ, то лучше с префиксами, чем без них. А то уникальность номеров фиг сделаешь)
Если РИБа абсолютно точно не будет, то они просто нафиг не нужны, ИМХО. Но этот вариант сомнителен. Потому что он может понадобиться.

(77)
Конечно, это самое из трех букв тоже может быть переменной. Нормальное вьетнамское имя.

(78) отзываю...не понял, что имеется ввиду префиксы при разработке)))

(75) ну вот пока платформа позволяет реквизиту формы случайно перепутаться с названием переменной (с учетом того что таковой дубль может появиться в будущем) - эта рекомендация является внутренней для разработчиков фирмы 1С.
любой стандарт не стоит ни гроша, если допускает возможность ошибки на проде!

(78) Согласен! Никогда не говори НИКОГДА. Даже вот в стабильной экономически стране индексы время от времени падают.