еще раз повторю вопрос. чем плохо "найти по наименованию" ?

Тем, что это *овнокод

👍

у меня в привилегированном модуле прекрасно работает код (в обычных формах):

Процедура СохранитьОбщуюНастройку(ИмяНастройки, Значение) Экспорт
 ХранилищеОбщихНастроек.Сохранить(, ИмяНастройки, Значение,, "$МойУникальныйИдентификатор$");
КонецПроцедуры

Функция ЗагрузитьОбщуюНастройку(ИмяНастройки) Экспорт
 Возврат ХранилищеОбщихНастроек.Загрузить(, ИмяНастройки,, "$МойУникальныйИдентификатор$");
КонецФункции

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

👍

Если ссылочная целостность и интерфейс по просмотру-редактированию из коробки не нужен, то воля твоя - хоть через хранение сериализованных значений в виде строки

я же писал выше - от задачи зависит

Чем только люди не готовы аргументировать, лишь бы по чертежу не делать)

говнокод - это переусложнение

добавить константу, добавить обработчик обновления версии для заполнения этой константы, где будет тоже самое "НайтиПоНаименованию()" - вот это говнокодище

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

Причем при разработке такого адаптера исполтзовать НайтиПоКоду вполне допустимо, потому что справочник не будет иметь прямого интерфейса работы с пользователем, а будет иметь апи через хранилище настроек

Ты реально не видишь проблему этого кода?

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

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

серилизация ссылки - это всего лишь ее ГУИД, а не все метаданные.  У меня не было проблем с восстановлением ссылок из хранилища при измененинии конфигурации

Выбор объекта метаданного для хранения это выбор структуры иб котораях подходит.
Выбор написать свои две функции извлечения значения и помещенич или обощить до хранилища настроек - это вопросы апи хранения настроек по конфигурации в целом.

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

Надо думать обо всех вариантах, а не только о том, что не встречалось, значит нет проблем.

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

👍😂