Надоел робот, который не воспринимает код, вроде и простой и говорит ИСПРАВЬ! Хоть и часы по рефакторингу у нас оплачиваются как и обычные рабочие часы, но лезть в готовый код, переделывать и по новой тестировать уже сданную работу как то не комильфо. И ладно ещё были бы серьезные ошибки, а то ругается на такую мелочь, как //Комментарий - отствие пробела между // и Комментарий )))). А теперь к сути. как бы вы написали конструкцию вида:

        Если ВидНеисправности = Справочники.ВидНеисправности .НайтиПоКоду("10464")
            ИЛИ  ВидНеисправности = Справочники.ВидНеисправности .НайтиПоКоду("10998")
            ИЛИ  ВидНеисправности = Справочники.ВидНеисправности .НайтиПоКоду("10999")
            ИЛИ  ВидНеисправности = Справочники.ВидНеисправности .НайтиПоКоду("10929")
            ИЛИ  ВидНеисправности = Справочники.ВидНеисправности .НайтиПоКоду("10467") Тогда
                ......
       КонецЕсли;

ругается что слишком сложная конструкция из ИЛИ

МассивВН = Новый Массив;
МассивВН.Добавить(Справочники.ВидыНеисправности.НайтиПоКоду("ХорошийКод"));
МассивВН.Добавить(Справочники.ВидыНеисправности.НайтиПоКоду("ОченьХорошийКод"));
МассивВН.Добавить(Справочники.ВидыНеисправности.НайтиПоКоду("ВащеОтстойныйКод"));
Если МассивВН.Найти(ВидНеисправности)<>Неопределено Тогда
    ...
КонецЕсли;

(1) Лучше соотвествие

Справочники.ВидНеисправности.Поломка
и т.п.

а правильно нужно галку какую поставить в справочник

(2) Массив быстрее

(0)
МассивКодовНеисправностей = Новый Массив;
МассивКодовНеисправностей.Добавить("10464");
МассивКодовНеисправностей.Добавить("...");
МассивКодовНеисправностей.Добавить("...");
МассивКодовНеисправностей.Добавить("...");

Если МассивКодовНеисправностей.Найти(ВидНеисправности.Код) <> Неопределено Тогда

(5) в массиве поиск - это перебор, а в соотвествии - хэшмап

Справочники.ВидНеисправности.Поломка();

Функция Поломка() Экспорт
Возврат Справочники.ВидНеисправности.ПолучитьСсылку(новый УникальныйИдентификатор(""));
КонецФункции

(7) Хосподя, у него пять элементов.

+ (6) Или можно строку с разделителями. Но строка ИМХО не так наглядно. И будет тяжелее в сопровождении.

(7) На создание и заполнение соответствия время потеряешь. Если Соответствие заполнить 1 раз и вызывать поиск 100 тогда возможно будет быстрее.

(11) все равно правильный вариант это (4)

(0) Я бы заменил на функцию. А список кодов на массив ссылок с кэшированием.

(13) Тогда уж запилить отдельный регистр сведений со списком требуемых видов неисправности, чтобы каждый раз в код не лезть.

(7) это так, но чтобы это знать, надо быть "одной ногой" в "нормальном" ЯП. т.е. по сути знать несколько ЯП и все -равно заниматься 1С)))

(14) Возможно, если он часто меняется.

(0)

Коды = Новый Структура("10464, 10998, ...");
Если Коды.Свойство(ВидНеисправности.Код) Тогда
// ...
КонецЕсли;


(12) Смотря по размеру справочника.
Если он большой, а в коде, как сейчас, вариантов 5 - то правильнее (14)

(0) У тебя ошибка не в сложном условии а в куче лишних дерганий БД через НайтиПоКоду

(17) Хороший вариант, если вместо Коды будет говорящее имя.

(17) низзя такие ключи в структуре.

(21) ну сделай массив или соответствие

(4) галку? интересно, но не понятно. выборка по справочнику потому и идет по нескольким кодам, потому как Виды Неисправностей, а точнее объекты ремонта разные. Грубо говоря если случились перечисленные неисправности, то сломался к примеру холодильник, а если другие, то радиоприемник, третьи - телевизор и т.д.

(21) хотя влом
Коды = Новый Структура("К10464, К10998, ...");
Если Коды.Свойство("К"+ВидНеисправности.Код) Тогда
// ...
КонецЕсли;

(24)+ или вместо "К" лучше|можно "_" ?

(23) Тогда не галку, а перечисление "ПоломаннаяХрень". И соответствующий реквизит в справочнике/регистре сведений.

(24) Если бы я был такой же злой, как средний мистянин, написал бы, что это - образец говнокода.

(24) имхо лучше так
Массив = СтрРазделить("10464, 10998, ...");

(25) а если код будет с пробелом или ещё каким символом запрещенным в ключах?

(28) Согласен

(27) Говнокод это в (0) У меня ближе к https://ru.wikipedia.org/wiki/Brainfuck - излишняя оптимизация

Суть что если у ТС работа с кодами то нехрен дергать базу
Коды из строки в некую структуру и ищи в ней

(0) А можно объединить эти Виды неисправностей общим признаком?
Тогда можно добавить реквизит в справочник и отбирать по этому признаку.

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

(32) в том то и дело что нет. По идее создается документ в котором группой является Неисправность, а подгруппы Виды неисправностей. При этом Объект ремонта для каждой подгруппы свой. Объекты - это отдельный справочник

(33) Из личного опыта: кусок кода в сабже - это показатель неэффективной архитектуры.
А чтобы дать эффективный ответ на вопрос в сабже - нужно видеть архитектуру системы в целом.

Подвожу итог: если указанный код тебя не особо напрягает - оставь как есть. Да, он кривоват, но работает же.
Придет время - и поправишь. Либо оно само отомрет за ненадобностью.

Как говорят китайцы: "Живи, сохраняя покой. Придет весна и цветы распустятся сами"...

(33) Ну соответствие же "многие к одному" типичное. (26) чем не устраивает?

(0) Для глупых проверок типа отсутствие пробела между // и Комментарий - лучше включить запрет их обнаружения - спецкомментарий в начале кода.

(0) за такой код линейкой бить надо

+37 чугунной

(38)+ по голове

(39) сначала по пальцам

(40) Лучше по яйцам.

(41) +100500 чтобы не размножались

перепись садистов ))

(36) ну, вообще-то, ненужные проверки отключаются в настройках. (полагаю, что у ТС модный нынче сонаркуб с bsl-плагином). только такие настройки обсуждаются в команде, а не по принципу "я хочу, я не хочу".
порядок в коде должен быть

(43) ты первый начал

(43) садист в данном случае это ТС
прикинь тебе в наследство достанется такая БД?

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

(44) дык такие конструкции однозначно проверки не должны пропускать, ибо овнокод )

(47) За НайтиПоКоду() и НайтиПоНаименованию() надо бить вот этой книжкой https://v8.1c.ru/metod/books/42696.htm

Соглашусь с (34). Проблема не в коде, а в архитектуре.
Либо переделать по человечески. И тогда надо пересматривать архитектуру.
Либо оставить пока как есть, отложив до тех времён, когда будет возможность сделать нормально.

(47) >> в тестовую проскочил аналог кода из (0), прог забыл убрать - так буча была поднята со стороны заказчика.
Тут всё таки обратная ситуация. *авнокод уже в проде. Любая оптимизация поиска или проверки по коду в справочнике даст только лишь оптимизированный *авнокод. Надо подход пересматривать, а не менять один *авнокод на другой - более оптимальный. ИМХО.

(17) Может вместо "Если Коды.Свойство(ВидНеисправности.Код) Тогда"
что-то типа :

Код_ = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ВидНеисправности, "Код");
Если Коды.Свойство(Код_) Тогда

(44) Да, но нет: в коде надежнее - завтра эту конфигурацию откроют удаленщики без сонаркуба, но с вручную подключенным BSL (Turboconf, phoenixbsl) - и им уже не надо заморачиваться.

(52) Если практикуется сонаркуб, то код удаленщиков так же обязан через него проходить.

(0) хороший робот, ободряю. А робот ободряет разработчиков.

(53) Да, но удаленщики проверяют свой код до сонаркуба.

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

(55) это проблемы удаленщиков. ну или дайте им свой .bsl-language-server.json

(50) "Либо оставить пока как есть, отложив до тех времён, когда будет возможность сделать нормально. " Такое время не наступает почти никогда