В типовых часто встречаю процедуры с огромным числом параметров и затем эти параметры передаются в те процедуры, которые из них вызываются и далее, далее, далее, насилуя стёк и мозги программистов, которые это все сопровождают.
Как считаете, процедуры с большим числом параметров - это зло или нет? Может имеет смысл передавать контекст-структуру с параметрами, а не тащить миллионы параметров.
Может имеет смысл в стандарте 1с-совместимо ограничить количество параметров процедур, чтобы программисты не плодили монстров и начать с типовых?

Зло. Большое.

2

Яд от лекарства отличает лишь дозировка.

(1) мотивируй, мотивируй
(2) Мотивируй, мотивируй.

Большое число параметров и вообще код типовых на 8ке считаю злом.

(3) То бишь? я согласен, что есть параметры, которые не передаются далее вглубь по рекурсии, а есть которые всегда строго передаются, вот их и надо пихать в структуру.

(5) О да, типовой код - это как УК, читаешь и рыдаешь... Хотя странно, казалось бы уж в 1С могли бы навести порядок.

(6) Считаю допустимым разумное количество разнородных параметров.

(8) +1
(0) Во всем должен быть разумный подход. В структурах иной раз такого наворотят, что разобраться там не проще, чем в куче параметров. Считаю, что разумное число параметров - 4-5, больше - уже делать не стоит, лучше сделать структуру. Только описать ее не забыть, ясен пень.

(0) зло. а за такое
>затем эти параметры передаются в те процедуры
я бы вобще убивал

Проголосовать забыл...

(7) гы... по-моему, ты учитываешь ответы не по аргументации, а в угоду собственной субъективности...
а вааще все должно быть в меру, но в то же время бывает всякое, поэтому:

(9) Дык надо комментить, комментить, батенька...

(13) Не возражаю! :)

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

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

Структуры - это правильно. Читаемость и сопровождаемость кода важнее долей процента производительности. Оптимизировать надо другие места.

(0) Я бы не сказал что это большое зло... но все таки нехорошо... потому

Зло по-любому. Кто не согласен - читать книжки по программированию!

(19) Наш человек.
(18) Тилигенция!

(19) Какой категоричный....
Давайте тогда определимся много - это сколько?

(16) Ну если есть необходимость вызывать методы из методов и т.д. по цепочке, то
может есть смысл пересмотреть структуру приложения.

Зло лучше передавать массивом

(23) Баш вспомнился... Про "теорию ЗЛА" :)

(21) ИМХО: пять - уже много.
Много параметров можно передавать другим способом (список, структура и прочее).

Да, пожалуй

1. Зло

(25) Это понятно... как передавать.
Обоснуй почему 5 - много.

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

так они так и делают, где параметры а где много структорой передают

(27) +
кроме того бывает много параметров когда было все написано... а тут нужно быстро прикрутить что-то забытое аналитиком... а срок - вчера.  ;-)

(27) Такое вот мнение исходя из опыта. Чем больше параметров - тем больше вероятность ошибки.

(29) Вот такик "аналитиков" нужно сразу отстреливать.

(30) Ты думаешь у меня мало опыта?  ;-)
Почему не 4 не 6, не 7 ???

(31) Гы. Они по большей части не в нашей власти...  ;-)

больше одного параметра - расстрел на месте.

До структур они так и не додумались

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

издержки отсутствия ООП :)

Чувствую мы придем к типизированности переменных

А мне пофигу. а вот за такое лапки бы пооткусывал

Функция ПолучитьЗначениеПраваПользователя(Право, ЗначениеПоУмолчанию = Неопределено, Пользователь = Неопределено) Экспорт

   ВозвращаемыеЗначения = Новый СписокЗначений;
   СписокНабораПрав = ПолучитьСписокНабораПрав(Пользователь);

   Запрос = Новый Запрос;

   Запрос.УстановитьПараметр("НаборПрав"        , СписокНабораПрав);
   Запрос.УстановитьПараметр("ПравоПользователя", Право);

   Запрос.Текст =
   "ВЫБРАТЬ
   |    Значение
   |ИЗ
   |    РегистрСведений.ЗначенияПравПользователя КАК РегистрЗначениеПрав
   |
   |ГДЕ
   |    Право = &ПравоПользователя
   | И НаборПрав В(&НаборПрав)
   |
   |";

   Выборка = Запрос.Выполнить().Выбрать();

   Если Выборка.Количество() < СписокНабораПрав.Количество() Тогда
       ВозвращаемыеЗначения.Добавить(ЗначениеПоУмолчанию);
   КонецЕсли;

   Пока Выборка.Следующий() Цикл
       Если ВозвращаемыеЗначения.НайтиПоЗначению(Выборка.Значение) = Неопределено Тогда
           ВозвращаемыеЗначения.Добавить(Выборка.Значение);
       КонецЕсли;
   КонецЦикла;

   Возврат ВозвращаемыеЗначения;

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

Функция РазрешитьНулевыеЦеныВОпте() Экспорт

   РазрешеноПроводить = ПолучитьЗначениеПраваПользователя(ПланыВидовХарактеристик.ПраваПользователей.РазрешитьНулевыеЦеныВОпте, Ложь);
   Если РазрешеноПроводить.Количество() = 0 Тогда
       Возврат Ложь;
   ИначеЕсли РазрешеноПроводить.Количество() > 1 Тогда
       Возврат Истина;
   Иначе
       Возврат РазрешеноПроводить[0].Значение;
   КонецЕсли;

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

(22) Что значит пересмотреть, гыгыгы. Ты про структурное программирование слыхал?  Процедуры должны быть маленькими. К тому же глобальные переменные - зло.

Типичный код в стиле а-ля Гений 1С:

Работа(П) {
 Инициировать(П)
 Обработать(П)
 Запротоколировать(П)
 Разрушить(П)
}

Инициировать(П) {}
Обработать(П) {}
Запротоколировать(П) {}
Разрушить(П) {}

(23) Массивом передают только сисадмины. Если бы еще в 1С были константы, фиг с ним, но по коду думать что такое П[3] означает и чем оно отличается от П[5] - маразм. Не на том экономите скорость, Шура.

(30) Блин, завидую тебе ВладЦ - ты знаешь все наперед, а ведь иногда бывает не то что аналитик ошибся, а задача слегка поменялась и вперед и с песней - передавай новых штук пять параметров по всей рекурсии вызовов!

(36) зачем помнить, если есть комментарии.

(38) В чем зло, лень анализировать код?

(42) + и копи-паст если параметры и переменные называть по человечески а не на птичем языке.  :-)

(41) Я не знаю всего наперед. Я знаю, что много параметров не есть хорошо.

(44) Зачем копи-паст. Если бы вместо структур вы передавали бы объекты, аналогично объявление структуры объекта было бы только в заголовке класса, никакого копи-паста. Привыкайте к ООП, асемблисты.

(45) О чем и речь. Много параметров - суть зло...

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

не вижу ничего плохого

счётчик гонит

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

Даешь типизацию!

(51) Странно... У меня умеет...

(53) уже после «(»?

(52) +1000

(54) Разумеется.

(54) у него 7.7. она умет

(57) Ну вот... Взял и все рассказал :)

Если руки кривые то даже ограничение кол-во параметров не поможет.

(56) ЛСД?

(60) С чего ты взял?

(58) ну так это с костылями умеет...

(62)А если этот "костыль" сделан гораздо грамотнее, чем умеют прогеры из 1С? Как-то Орефков по пунктам расписывал преимущества семерошного телепата перед восьмерошным.
И пунктов этих получилось ох как много...
P.S. И это, тебе шашечки или ехать?

(62) Без костылей в 7.7 совсем скучно :) И вообще, у кого костыль, а у кого средство разработки :)

(64) " И вообще, у кого костыль, а у кого средство разработки " - супер! Всеми руками за эту фразу :)

(39)
1.Что значит пересмотреть
суть в том что, если в вызове одной функций вызывается иерархический вызов
других функций с теми же параметрами то что-то в структуре данной реализации
надо пересмотреть

2. роцедуры должны быть маленькими. Я не утверждал обратное

3.  К тому же глобальные переменные - зло не всегда.

4. Типичный код в стиле а-ля
ИМХО процедурный с использованием структур в качестве параметров в вызовах функций
5. и что Вас так рассмешило в (15) и (22)...

Однозначно, п.1, бесило ещё со времён Фортрана.
4, самое много 5 параметров.

(40) ну тогда СпискомЗначений

(66) ГП - зло, т.к. функция теряет изолированность.
Насчет пункта 1 - приведите пример, когда надо пересмотреть код, что-то я таких примеров в практике не припомню. Вы имеете ввиду не спускать ничего вниз в субпроцедуры, а чисто загнать все в одну большую процедуру?

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

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

(3) +1

(0) "Может имеет смысл передавать контекст-структуру с параметрами, а не тащить миллионы параметров"
Вопрос уже обсуждался, причем тобой же :)
Решение - сделать возможность программисту создавать собственные классы.

(71) Не, одна большая процедура это точно зло ...

Достаточно сделать передачу параметров по имени, как в Барсике и все будет замечательно. Так не дождемся же...

.

(74) имелось ввиду уровень вложенности...

(0) Помню ещё в студенческие годы на Паскале написал программу, где у процедуры было около 24 параметров. Я её конечно сдал, но при этом преподавтеля просил код не смотреть. Слава Бргу он моей просьбе внял, а то бы краснеть пришлось. Но тогда времени в обрез было. А так если структура данных достаточно продумана, то много параметров быть не должно. А 1С  - это не то. что заслуживают отечественные программисты.

(78) А чего они заслуживают?

(79) Удобоваримой среды разработки. А 1С надо экспортировать за бугор. Пусть буржуи мучаются.

(73) классы тебе никто не мешает создавать (обработки без форм в 1С).
Но структуры - лучше. ;-)

(81) Ты вообще в курсе, что такое классы?

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

(82) В 1992-1997 году когда я учился на программиста, С++ уже было изобретено и нас сия чаша не минула, если ты о классах, гыгыгы.

(82) у обработок нет наследования, а так вроде и инкапсуляция и прочее...

(82) разве что конструктора и деструктора нет

Помню на заре 8-ки, часто говорилось про минимальное количество кода для программирования в 8-ке, но чуда не случилось. Ноборот появились мега-монстры, типа УПП. Все изучают километры кода прогов из 1С, только для того чтобы подправить проводку...
Я выступаю за создание лайт-версий типовых. Понятных и удобных в работе!!!

(86) при нетипизированности не может быть не виртуальных методов
А вообще какой там ООП?

(87) Ну парадигма-то не поменялась. Можно конечно обойтись и без ООП, но тогда надо грамотно писать код. Ключевое слово - грамотно. ;-) Но если бы код был грамотным, такого зверства с толпой параметров бы не было. ;-)

(87) Если бы была одна УПП и ее можно было расчленять на ЗУП, БП и УТ, тогда твоя мечта бы сбылась. Но так не умеют пока еще... Вот когда сумеют, тогда и будет 9.0.

не понятен критерий "большое" количество параметров.
Если речь про удобство восприятия, то известно, что воспринимается максимум до 5-7 объектов.

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

Объединение параметров только с целью уменьшения их числа приведет к неудобствам сравнимым с неудобствами при большом количестве параметров.

Т.е. в каждом случае решение по объединению параметров в структуру надо принимать по контексту.

(89) Из заявления о неграмотности кода следуют два вывода в то время как посте приведен только один. На самом деле выводов 2:
1. Неграмотный код.
2. Неграмотный автор утверждения.
Очевидно что второй вариант автором не рассматривается и принимается за аксиому то что автор не менее как родоначальник и непогрешимый святой отец "всея программироваения".

(91) Вот тебе универсальное правило.
Если есть процедура А и из нее вызывается другая процедура Б, которая использует два или более параметров процедуры А, то эти параметры при вызове процедуры А должны быть "упакованы" в структуру. Все, точка.

Если из процедуры А другие процедуры не вызываются, то хот 40 параметров юзай.
Только не забудь, что возможно, тебе захочется разбить код процедуры на части и тогда тебе придется вызывать подпроцедуры. Также не забывай что ты возможно захочешь вынести процедуру в общий модуль и тогда в параметры процедуры нужно будет добавить все глобальные переменные.

(92) Боже мой, как тяжело с дятлами, особенно самоуверенными.

Конечно зло. Больше 6 стараюсь не делать.

(93) это Ваш копирайт?? Или Вы это где то прочитали ?? (спрашиваю совершенно без иронии)

(93) твое утверждение звучит не менее самоуверенней :)

(81) посмеялся :)

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

(81) ИногдаЛучшеМолчатьЧемГоворить = class(Гений 1С)

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

в любом деле подход должен быть разумным. в (0) полно туфты.
голосовать не буду. если кто то желает писать так что бы все параметры функции были в структуре то никто не мешает ему написать конфигурацию с нуля "Управление Производственным Предприятием С Модным Вызовом Функций И Процедур Где Параметры Передаются Структурой". УППСМВФИПГППС сокращенно. название дарю.

(93) правило не универсальное. ты выделил только один момент и затачиваешь под него кодинг.

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

(102) Ты упал в моих глазах, доказывать ничего не хочу, на переэкзаменовку, т.е. на повторную вычитку ветки.

Самое злое число параметров - 666 Токо настоящий Сотона могет понять такую функцию/процедуру

(103) ай-яй-яй, как же так, какой удар от Гения :))
доказывать ничего не надо, переэкзаменовываься тоже не надо,
читай мой пост, там все основные аргументы встречавшиеся в ветке есть.

массив, структура
а если хочется

Процедура Проц1 (Парам1, Знач Парам2, Знач Парам3)

КонецПроцедуры

(105) Взаимно.

(93) Да, заметно как ты сам от себя устаешь.

Есть такой язык программирования Forth, вот там эта проблема решена гениально. :)

(7) >> О да, типовой код - это как УК, читаешь и рыдаешь... Хотя странно, казалось бы уж в 1С могли бы навести порядок.

В 1С писателям конфы мало платят и не особо считаются, да и условия жеские - почти все остаются после работы.

(110) Это факты или пиар?

(111) второе факты

(111) прийди как-нибудь на Никоновский 26 и посмотри когда все уходят :)

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

Ну и до этого слышал что у них так.

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

(114) меня тоже приглашали в УТ, я уж было готов был пойти, но потом вспомнил, что УТ+БУ+ЗУП <> УПП и подумал, нафига распыляться на УТ, лучше приложить силы в другой области.

(116) УПП состоит из частей Производство+БП+УТ+ЗУП
Т.е. прийдя в отдел разработки УПП, ты будешь заниматься частью производства

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