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

Функция ДобавитьОбъектНаПанельЗадач(ДокументHTML,
ПанельЗадачСсылка,
ДеревоОбъектов,
ТаблицаОбъектов,
ОбъектПанелиЗадач = Неопределено,
ОбъектРодитель = Неопределено,
ОбъектИБ = Неопределено,
УИД = "",
ИдентификаторОбъекта = "",
ИдентификаторОписания = "",
ДополнительныеПараметры = Неопределено) Экспорт

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

ЗЫ: про рекомендации от 1С я в курсе, мне хочется знать мнение реальных людей, который кодят код.

я бы структурой.
Причем фиксированной

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

Соответствием

Группировать в структуры по смыслу.

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


Функция ДобавитьОбъектНаПанельЗадач(ДокументHTML,
ПанельЗадачСсылка,
ДеревоОбъектов,
ТаблицаОбъектов,
ОбъектПанелиЗадач = Неопределено,
ОбъектРодитель = Неопределено,
ОбъектИБ = Неопределено,
УИД = "",
ИдентификаторОбъекта = "",
ИдентификаторОписания = "",
ДополнительныеПараметры = Неопределено) Экспорт

  Возврат ДобавитьОбъектНаПанельЗадач_наСервере(ДокументHTML,
ПанельЗадачСсылка,
ДеревоОбъектов,
ТаблицаОбъектов,
ОбъектПанелиЗадач = Неопределено,
ОбъектРодитель = Неопределено,
ОбъектИБ = Неопределено,
УИД = "",
ИдентификаторОбъекта = "",
ИдентификаторОписания = "",
ДополнительныеПараметры = Неопределено)

КонецФункции

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

(6) Это мелочь, по сравнению с любовью 1С менять параметры своих функций

Вот так и появилось ООП когда-то :)
Некая структура + несколько функций для работы с ней.

(3) ы?

(9) в соответствии обращаться к элементу проще Параметры[...]

(5) Не надо грязи, я не 1С!
(6) ФИшка не только в том, что могут перепутать, а в том, что бОльшая часть из низ необязательные. 4 первых - обязательные, причем в пределах одного модуля (того, который пишет разработчик) они не меняются вообще, а из 6-ти последующих обязательны только один или два (указатель на сам объект и его родителя). Со структурой может наступить путанница, если например задать значение параметра "ОбъектИБ" и забыть почистить "ОбъектПанелиЗадач".

*Параметры.Получить[имя] т.е.

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

так писанины меньше и нагляднее:

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

(15) может и так, но в типовых это сплошь и рядом.

одной структурой

(15) Заготовить структуру заранее, кодер пусть только параметры в ней устанавливает.

(14) Да блин уже сами начали путаться в такой писанине:

       Для Каждого СостояниеЗадачиЭлемент Из КоллекцияДанных_СостояниеЗадачи Цикл
           // Добавляем состояния задачи на поле
           КэнВизуализацияСервер.ДобавитьОбъектНаПанельЗадач(ПолеДокументHTML, ПанельЗадачСсылка, ДеревоОбъектов, ТаблицаОбъектов,,,,,"Состояние_" + СостояниеЗадачиЭлемент.Состояние, "Панель");
           
       КонецЦикла;
       ДополнительныеПараметры = Новый Структура("НеДобавлятьЕслиНеНайденРодитель", Истина);
       Для Каждого ЗадачаЭлемент Из КоллекцияДанных_Задачи Цикл
           КэнВизуализацияСервер.ДобавитьОбъектНаПанельЗадач(ПолеДокументHTML, ПанельЗадачСсылка, ДеревоОбъектов, ТаблицаОбъектов,, "Состояние_" + ЗадачаЭлемент.СостояниеЗадачи, ЗадачаЭлемент.Ссылка,, "Задача_" + ЗадачаЭлемент.Код, "Задача", ДополнительныеПараметры);
       КонецЦикла;

Мне кажется, в таких случаях структура удобнее.

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

(21) Так структуру параметров можно сделать единую для всех вызовов функций. По сути у нас идет управление некими объектами на поле HTML: размещение, перемещение, удаление, изменение размеров или стилей. Структуру параметров заполнили один раз значениями по умолчанию, а далее просто устанавливаем нужного родителя и сам объект и кидаем эту структуру на вход нужной функции - "ДобавитьОбъектНаПанельЗадач", "УдалитьОбъектСПанелиЗадач" и т.д.

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