Правильно ли с методологической точки зрения в конфигурации использовать НайтиПоИдентификатору(УИД) для подстановки неких "константных" значений в алгоритмах (склад по умолчанию, учетная запись эл.почты для рассылки и т.д.)? Чем это плохо?
Вместо, например, использования объекта метаданных Константа или же РегистрСведений.
Не первый раз замечаю применение такого подхода в рабочих базах.. Своего рода обход запрета на НайтиПоНаименованию().

Лучше и предопределённые значения, или РС

(0) В крайней военной ситуации допустимо. В качестве исключения, если есть гарантия, что элемент не удалят. И если другие способы невозможны.

а причём тут уид? это же метод для работы с коллекциями форм

(3)  Я ошибся.
ПолучитьСсылку()

(2) А можете пример тех случаев, когда "другие способы невозможны" ?

(5) например, нельзя курочить конфигурацию

(5) Например, нельзя менять конфигурацию

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

(6), (7) Что, даже нет никакого регистра каких-нить допсведений?

(8) И что, предопределенный элемент спасет в такой ситуации? А они массово применяются везде.

На самый крайняк, когда вообще труба, нужно не писать НайтиПоИдентификатору(УИД), а делать функцию типа ПолучитьОсновнойСклад(), а в ней уже писать НайтиПоИдентификатору(УИД), так хоть будет понятно, про что речь

(0) Если нельзя изменять конфигурацию, то правильно.

(0) Неправильно, если планируется многократное использование в течении длительного времени.

(10) Это точно мне вопрос?

(12) Нельзя менять конфигурацию?
Срочно! начинаем говнокодить!

(15) +100500

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

(15) Почему это говнокод? А как лучше? Поиск по наименованию?
Даже когда можно изменять конфигурацию есть смысл поиска по УИДу. Например, у объекта есть куча дополнительных реквизитов. Чтобы их использовать в коде, правильней выполнять поиск по УИДу, а не создавать кучу констант.

(18) Я понимаю, что это сложно, практически нереально, но все-таки попробуй прочитать всю ветку, а не последние два поста, там как бы есть ответ на твой вопрос

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

(12) Обратная сторона медали же тоже есть такого подхода?
Но я пока это не вижу, вот в (8) описал проблемы возможные. И я думаю, что неустойчивость кода возникает + увеличивает время на расследование проблемы, ну чисто гипотетически если вдруг на этом месте она будет..
(11) Одназначно -) ощущение, что ты уже не одну собаку на этом съел.

(20) Ставит условие говнокодить? o_O

Одноразовая задача?
Срочно! начинаем говнокодить!

(21) 18 лет программирую

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

(20) А чем мотивируют такое условие?

(25) чтобы обновляться без программистов

(26) Так ведь ПолучитьСсылку() - это уже влез в код. Без программистов никак уже.

(24) Рукалицо
Запрет как раз в голове заказчика, одинеснику пофиг
А заказчик считает, что если включили возможность менять, сразу все затопило говнокодом с конфу обновлять стало если и возможно, то за безумные деньги
Чем больше знакомлюсь с отдельными представителями профессии, тем больше соглашаюсь с такими заказчиками

(26) Хотя если это внешняя обработка...

(15) а расширения не предлагать?

(30) Ну почему же, можно предлагать, особенно на свежих-то конфах

(30) А вот интересно, если добавить расширение со "справочником констант", то как юзерам дать доступ к этому справочнику? Захватывать роли в расширение? Или добавлять свою роль и иметь гемор с обновлением профилей доступа? Или работать с этими объектами только под полными правами?

(32) Конечно свою, без всякого геморроя
Но вообще обычно такие вещи редактируются только под полными правами, а программно читаются в привилегированном режиме без всяких прав

(32) с константами проблематично, но если очень хочется, то можно создать список констант в расширении и брать их оттуда

до сих пор были проблемы с расширениями данных
режим совместимости..

тогду уж лучше предопределенный создать и ему уид назначить

(33) Новая роль "без всякого геморроя" и последние типовые - несовместимые вещи :)

(37) Ну, кому-то и ложкой в рот попасть, когда суп ешь, тяжело

(34) "создать список констант в расширении и брать их оттуда" - про это и речь, этот список можно создать в виде нового объекта метаданных, но к нему надо дать всем доступ на чтение.
Как этот доступ делается? Я с расширениями пока не работал, поэтому интересуюсь.

(36) ходили, знаем.... создали в УТ свои предопределенные виды оплаты .... В через месяц пришлось менять им коды во всех 20 магазинах, потому как в новом релизе 1С ввела еще несколько предопределенных видов оплат

(39) Методы разные. Можно и роли создать в расширении, которые дают доступ к определенному набору констант. По идее в расширении все равно роли потребуются, если это конечно не мелкая дописка к основной

(40) вы доработки не префиксируете?

(40) Че-то я малость не понял.
Как новые предопределенные виды оплаты повлияли на УИДы имеющихся?

(42) есть смысл? вообще сейчас ведем все доработки в расширениях, но что бы, то было

(42) На фикси сначала лень и незачем, а потом (40)

(43) не в уид дело ... там ВПФ-ки подхватывали эти виды оплаты по коду
(45) не мной это было сделано. Наоборот я все доработки до меня сделанные вынес в расширения, чтобы дальше гемора не было

(46)+  Единственное с чем не смог справиться - это с правильной печатью чеков на фискальнике... Пришлось ковырять ОбщийМодуль..... потому как на эту проблему 1С забило... хоть проблема висит ещё с начала года. Релиз за релизом выходит и баг тот же

(46) все равно не понимаю, ведь они предопределенные - зачем их искать по коду? -)
Вот, получается в данном случае ПолучитьСсылку() выглядит более устойчивым вариантом в сравнении с НайтиПоКоду()

20 видов оплаты, и если на каждый вид оплаты выполнять ПолучитьСсылку() под свое предназначение.. И все-таки за такими конструкция возникает дополнительная ответственность у программиста, если изменится бизнес-правило.

(23) Поделись опытом.. Есть подобные проблемы в других языках программирования? Там наверное похлеще все, т.к. больше места для фантазии с кодом..

А если сопоставить временные затраты на такой маленький "говнокодик" с трудозатратами на полноценную разработку (через расширение, роли, константы/ р/с) - окупится ли это? Ну возникнет раз в год ошибка, поправится за часик другой...

(46) расширение никак не спасает

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

(50) пока что проблем с расширениями у меня не было.... Конечно не так просто, но можно практически всё, кроме корректировки ОбщихМодулей..

(52) от той проблемы которую ты описал расширение не спасет

(52) "кроме корректировки ОбщихМодулей.." - почему?