Красота разработки в 1С, или художественная верстка кода

02.06.22

Разработка - Рефакторинг и качество кода

Рекомендации по верстке и организации кода в 1С, которые я вывел для себя. P.S. Нет, это не про комментарии и номера версий.

Я буду употреблять слово «Функция», но под этим буду иметь в виду «Функции» и «Процедуры».

Большинство статей по оформлению кода это описание комментариев, заголовков функций и нумерации обработок. Но разве на этом заканчивается правила написания чистого кода? Вам будет важно, кто написал код, если это процедура на 5000 строк, которая делает «всё»? Ну если только для того, чтобы проклясть этого человека, да и дата написания кода вам не особо поможет. А что же тогда важно? По моему мнению, это читаемость и простота отладки. Не будем сейчас разбирать правильность и скорость выполнения, а поговорим только об оформлении.

Существует 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками и, взяв 2 за отправную точку, я вывел для себя следующие правила написания кода для 1С.

  1. Одна функция – одно действие. Это убирает задвоение кода (на практике я встречал сокращения строк кода после рефакторинга в 3 раза!) Это позволяет использовать функции повторно, а не каждый раз заниматься написанием заново. 
     
  2. Размещать функции там, к чему функция относятся. То есть не надо все функции стараться запихнуть в один модуль. Чем точней вы будете размещать функции, тем чаще вы будите их находить и использовать повторно. Если функция относится к документу реализации, то надо ее размещать в менеджере реализации. Так вы будете чаще находить уже готовые функции, даже если забыли, что их когда-то писали.
     
  3. Делите общие модули по логике работы. Почти то же самое, что и пункт 2, но про общие модули. Не надо делать модуль с именем "Разное" или "Общее". Называйте их "РаботаСТабличнойЧастьюДокументов", "ЗагрузкаДанныхFTP" и не надо бояться модулей в одну функцию, придет время и вы его расширите, да если даже и нет, зато не будет бардака в других модулях.
     
  4. Не называйте функции «от балды». Называйте максимально однотипно, например я взял следующий формат. Все функции должны начинаться с глагола и обязательно содержать в наименовании тип данных, с чем производится действие. («Заполнить», «Получить», «Найти» и т.д.) + («Документ», «Справочник», «Структура», «ТаблицаЗначений» и т.д.). Это позволит быстрей читать свой же код, а не раздумывать на тему, что я имел в виду, когда назвал функцию "БыстроСпрВ(до)"
     
  5. Специально для не любителей «НЕ» и «<>» в условиях. Где-то я встречал рекомендацию, и она мне понравилась: В условиях первая группа команд та, которая чаще выполняется. Так код смотрится читабельней.
     
  6. Результат условия в одну команду пишите одной строкой. Самое частое, где я это использую, это когда после ТОГДА идет только ВОЗВРАТ; или ПРОДОЛЖИТЬ;. Исключение если есть ИНАЧЕ или ИНАЧЕЕСЛИ.

    Когда растягивают короткое условие на 3 (иногда 5) строк. Читабельность это только ухудшает.

     
  7. Тексты запросов выносите в отдельные функции. Длинные запросы, больше обычной выборки с условием, стоит выносить в отдельную функцию. Код становится компактней, а для отладки текста запроса код модуля не нужен.

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

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

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

     
  11. Объединяйте множество параметров в структуры. Если вам надо получить/передать более шести параметров в функцию, то лучше создать Структуру и передать их в ней (или часть параметров передать в структуре), и не забыв сделать описание этой структуры в описании.

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

     
  13. Собирайте строки в переменные. Не стоит собирать строки сразу при заполнении реквизита или вызове метода. Сделайте это в отдельной переменной и присвойте, а еще лучше в отдельной функции, но это уже в зависимости от сложности. Это спасет вас от длинных строк вызовов.

     
  14. Возврат значений в функциях делайте одного типа. Если Функция возвращает объект, то она должна возвращать или объект или пустую ссылку (иногда можно Неопределено). Если функция возвращает коллекцию, то она всегда должна возвращать коллекцию. Это спасет вас от разных ошибок при обработке результата выполнения этих функций. (автор идеи ksely)
     
  15.  В функциях стараться размещать "Возврат" в конце. Конечно это правило далеко не всегда выполнимо, но если функция это допускает, то лучше это правило выполнять. Это вам поможет при отладке, когда мельком глянув текст и поставив точку остановки вы сразу на неё попадете.
     

     

P.S. Буду обновлять, если что-то понравится из комментариев или вспомнится.

стиль разработка рефакторинг код

См. также

Рефакторинг и качество кода Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим основные принципы шаблона проектирования "Стратегия" на простом примере.

25.06.2024    2570    MadRave    33    

22

Рефакторинг и качество кода Программист Платформа 1С v8.3 Абонемент ($m)

В статье расскажу и покажу процесс проведения Code-review на примере обработки с GitHub.

1 стартмани

04.06.2024    5046    mrXoxot    55    

40

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    10822    artbear    84    

104

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    3118    DrAku1a    15    

35

Рефакторинг и качество кода Программист Бесплатно (free)

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

01.04.2024    910    Prepod2003    6    

2

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1682    ZhokhovM    5    

4

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    3435    ZhokhovM    4    

10
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. surikateg 02.06.22 20:42 Сейчас в теме
По п. 4. я бы лучше так сделал:
Процедура Хорошо()

ТекстЗапросаПоискаРеализации = ТекстЗапросаПоискаРеализации();

КонецПроцедуры
2. TimofeySin 172 02.06.22 20:56 Сейчас в теме
(1) с глаголов начнинать функции надо :). Я это с стандартов java стырил, там даже idea подчеркивает не правильное название.
DELOVOYDOM; Риник; +2 Ответить
24. NeviD 04.06.22 09:58 Сейчас в теме
(2) По стандартам 1С как раз не надо, особенно не нужно использовать слово "Получить.."
Тогда код читается легче - сразу читаем что вернется из функции, как будто это уже переменная, а не вызов функции.
kaaasteeen; bor10811; McFlaren; Дмитрий74Чел; dvsidelnikov; Irwin; tbkvpvl; Revachol; zqzq; cleaner_it; +10 Ответить
30. FatPanzer 05.06.22 23:33 Сейчас в теме
(24) Да, тут еще и удобство поиска процедуры. Когда у тебя в списке 100 функций Получить...ХХХ() - замучаешься искать. Гораздо удобнее, когда именование метода начинается с сущности, а не с глагола.
Olenevod; dvsidelnikov; unknown181538; zqzq; +4 Ответить
69. DELOVOYDOM 14.02.24 13:59 Сейчас в теме
(30) Зачем вам начинать с сущности, если сущность при грамотном написании кода у вас в контексте? Если с сущности то теряется способ получения информации. Поэтому стандарты как правило с глагола. ПолучитьЗавершенныеБизнесПроцессы(Отбор), УдалитьБизнесПроцессы(Отбор),ЗапуститьБизнесПроцесс(СсылкаСправочник, ШаблонБизнесПроцесса) возвращает экземпляр процесса. Попробуйте переписать это начиная с сущности. Получиться где удалить там булево а не сущность, запустить там экземпляр а где отбор там вообще набор экземпляров
3. malikov_pro 1313 02.06.22 21:19 Сейчас в теме
(1) + за попытку переложить "Чистый код" на 1С.

"Удаляйте ненужный код" - работает при наличии хранилища или git.

"Объявляйте переменные в начале функции" - если их больше 10, то имеет смысл в декомпозиции функции.

"ФИО = Фамилия + Символы.ВК + Имя + Символы.ВК + Отчество;" - Массив и стрСоединить, чтобы не забыть разделитель.
Риник; +1 Ответить
4. vano-ekt 124 02.06.22 22:13 Сейчас в теме
Процедура Хорошо(Значение)

К-к-к-комбо!
из "Системы стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8"?
2. Имена процедур, функций и формальных параметров следует образовывать от терминов предметной области таким образом, чтобы из имени было понятно назначение. Следует стремиться к тому, чтобы имена были "говорящими" (документировали сами себя).

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

ей лет 15+, не поленитесь, почитайте
https://its.1c.ru/db/v8std
bor10811; Дмитрий74Чел; dvsidelnikov; Irwin; cleaner_it; Andreeei; Revachol; tindir; +8 Ответить
7. tindir 03.06.22 05:51 Сейчас в теме
(4) Стандарты в ИТС написаны, что бы можно было побольше "бумаги" напихать в коробку ЕРП и как следствие продать подороже =)
5. SerVer1C 785 02.06.22 23:06 Сейчас в теме
Где-то я встречал рекомендацию, и она мне понравилась: В условиях первая группа команд та, которая чаще выполняется.

Это пошло из "нативных" языков. Суть в том, чтобы попасть в условие предсказателя ветвления на процессоре. Не уверен, что это актуально в виртуальной машине 1с. Но по привычке всегда так пишу )
Советы хорошие. Вот бы ваши рекомендации, да богу погромистам в уши. Может тогда чуть меньше будет говнокода.
cleaner_it; +1 Ответить
6. recon 39 03.06.22 01:10 Сейчас в теме
Актуально т.к. в 1С механизм условий работает как в jave ленивый механизм (&& и ||) - если первое условие истина то второе не выполняется
8. maksa2005 540 03.06.22 06:30 Сейчас в теме
Процедура Хорошо(Значение)
   
   Если Значение = Неопределено Тогда Возврат ложь; КонецЕсли;	
   
   Возврат Истина;
   
КонецПроцедуры


Функция Плохо(Значение)

	Если Значение = Неопределено Тогда 
	   ЭтоНеопределено = Истина; 
    Иначе
	   ЭтоНеопределено = Ложь;
    КонецЕсли;	
   
   Возврат ЭтоНеопределено;	
КонецФункции
Показать

Не согласен полностью!
Вот так читабельно одной строчкой (хоть и не на языке 1с, но суть одна)?

ЕСЛИ([Согласован (ФЭО)]=[Да] И [Направлять в лист ожидания ]=[Нет];Нет;[Операция_платежей]=[Отдел ПСО] ИЛИ [Операция_платежей]=[Отдел снабжения] ИЛИ [Операция_платежей]=[Отдел маркетинга] ИЛИ [Операция_платежей]=[Транспортный отдел] ИЛИ [Направлять в лист ожидания ]=[Да] ИЛИ [Сумма заявки, руб.]<>0 И [Направлять в лист ожидания ]=[Да] ИЛИ [Операция_платежей]=[Отдел продаж] ИЛИ НЕ ([Организация]=[_____] И ([Контрагент]=[_______] ИЛИ [Контрагент]=[РОСТЕЛЕКОМ, ПАО] ИЛИ [Контрагент]=[ВОСТОК ______, АО] ИЛИ [Контрагент]=[_____, ОАО] ИЛИ [Контрагент]=[_____, ПАО])) И [Направлять в лист ожидания ]=[Да])


Не комментируйте каждую строку.

Вот мне заняться больше нечем как рассказывать что и как работает каждая функция для другого программиста.
Риник; Irwin; RocKeR_13; tbkvpvl; ig1082; proglex; ejijoka; SerjK88; cleaner_it; tsatsur; Fedos; Revachol; LeXXeR; zadoy; Drivingblind; user1455510; +16 Ответить
22. SerVer1C 785 03.06.22 16:40 Сейчас в теме
Процедура Отлично(Значение)
   
   Возврат ?(Значение = Неопределено, Истина, Ложь);
   
КонецПроцедуры
Риник; cleaner_it; DrAku1a; ixijixi; +4 Ответить
25. ixijixi 1833 04.06.22 10:13 Сейчас в теме
(22)
Процедура Превосходно(Значение)
   
   Возврат Значение = Неопределено;
   
КонецПроцедуры
kaaasteeen; Риник; SagittariusA; Drivingblind; Slypower; Vyacheslide; G_116449793522595596167; unknown181538; 0x00; dmpas; cleaner_it; tsatsur; maksa2005; opx; myoker; serg-lom89; khristal; Shmell; FatPanzer; Kutuzov; zaichikov; Revachol; zadoy; DrAku1a; ivanov660; +25 1 Ответить
42. SerVer1C 785 06.06.22 15:20 Сейчас в теме
(25) Это частный случай. Имелось ввиду, что конструкцию <Если Тогда Иначе КонецЕсли>, в которой по 1 строке присваивания на каждую ветку, можно заменить тернарным оператором.
Так то и ежу понятно, что можно и не вызывать процедуру "Превосходно", а сразу написать вместо нее "= Значение = Неопределено".
43. ixijixi 1833 06.06.22 15:48 Сейчас в теме
(42) Да это все не важно. А вот то, что у нас с Вами процедуры возвращают значения - вот это номер! =)
HaIIpuKoJIe; work.sable; Altez; Дмитрий74Чел; insurgut; arakelyan; G_116449793522595596167; cleaner_it; SerVer1C; 0x00; +10 Ответить
44. SerVer1C 785 06.06.22 15:54 Сейчас в теме
(43) это всё злостный копипаст на замыленный глаз )))
work.sable; cleaner_it; ixijixi; +3 Ответить
53. unknown181538 158 16.06.22 12:25 Сейчас в теме
(8) Мне попадался код, где старались много условия запихнуть в одну строку. Мне было нечитабельно зачастую.
Плюс, это не очень удобно для отладки.
Ну, наверное, еще от контекста зависит.
9. pavlov_dv 03.06.22 06:56 Сейчас в теме
12. Объявляйте переменные в начале функции. 1С позволяет объявлять переменные в любом месте кода и инициализировать сразу, но для чтения удобней, когда они все объявляются и инициализируются в самом начале. Тогда сразу видно, какие параметры приходят в функцию, и какие переменные используются внутри


Действительно, некоторые ЯП требуют именно такое поведение, например, Pascal.
Но если язык позволяет - рекомендуется объявлять переменные по возможности ближе к месту использования.
Есть специальные метрики для анализа кода в этом разрезе: "Интервал" и "Время жизни".

Метрика "Интервал" показывает усредненное значение количества строк между местами использованиями переменной.
Метрика "Время жизни" показывает количество строк между первым и последним использованием переменной.

Чем меньше значение этих метрик, тем:
а) меньше "окно уязвимости" - вероятность изменения переменной между вызовами. Умышленного или неумышленного;
б) меньше неоптимальных затрат памяти;
в) проще программисту держать в голове этот кусок кода.
Риник; work.sable; Altez; unknown181538; zqzq; cleaner_it; ltfriend; begemot; Rokky78; tormozit; json; mrChOP93; +12 Ответить
20. TimofeySin 172 03.06.22 11:20 Сейчас в теме
(9) Если придерживаться первого правила, то метрика у вас всегда будет отличная, Но если вы адепт "God function", то лучше объявлять и сразу инициализировать переменную (а то вдруг вы её объявляли пару экранов назад). :)
10. Drivingblind 229 03.06.22 07:13 Сейчас в теме
Процедура Хорошо(Значение)
   
   Если Значение = Неопределено Тогда Возврат ложь; КонецЕсли;	
   
   Возврат Истина;
   
КонецПроцедуры

в таких случаях имеет смысл использовать тернарный оператор
Риник; cleaner_it; begemot; Faradel; +4 Ответить
11. mrChOP93 97 03.06.22 07:14 Сейчас в теме
6) имхо, куда понятнее будет выглядеть так:

Процедура Хорошо(Значение)
   
   Возврат ?(Значение = Неопределено, Ложь, Истина);
   
КонецПроцедуры


7) я для длинных запросов делаю область, так его можно свернуть + не надо между функциями скакать, что бы подправить обработку результата после изменения запроса.
Риник; Fril; zqzq; akR00b; flanchev; SerVer1C; pavlov_dv; +7 Ответить
12. pavlov_dv 03.06.22 07:31 Сейчас в теме
(11)

Можно еще короче )):
Процедура Хорошо (Значение)

      Возврат Значение <> Неопределено;

КонецПроцедуры
Риник; mrChOP93; +2 Ответить
13. mrChOP93 97 03.06.22 07:38 Сейчас в теме
(12) Именно в текущем случае- да. Но если выдаваемый результат будет не булево, тогда надо использовать тернарный оператор)
17. pavlov_dv 03.06.22 07:46 Сейчас в теме
(13)

Тип данных параметра Значение в текущем примере особого значения не имеет.

Результат выражения
Значение <> Неопределено
будет булевым всегда.
Функция Хорошо(Значение) (судя по коду) должна возвращать Истина только в одном случае: когда
Значение = Неопределено

Соответственно, тип данных параметра может быть любым. Мы же можем любое значение сравнить с Неопределено )
18. mrChOP93 97 03.06.22 08:09 Сейчас в теме
(17) Я имею ввиду возвращаемое значение функцией, а не передаваемый ей параметр)
pavlov_dv; +1 Ответить
48. zqzq 25 07.06.22 09:19 Сейчас в теме
(13) Если нужно будет будущем добавить строку кода в ветку, то тернарный оператор -- всё.
В отличие от функциональных языков программирования, где сам оператор if возвращает значение.

Поэтому не люблю этот тернарный оператор + читабельность не очень.
И Если в одну строку тоже не нужно писать.
14. user1455510 03.06.22 07:38 Сейчас в теме
Рекомендации по верстке и организации кода в 1С

Без пруфов - это всё вкусовщина.

Вы потрудились систематизировать свои знания - за это +, но есть и минус.

Уважаемый автор, если не хотите быть голословными - рекомендую отделить Свои правила, Правила сложившиеся на проекте и Общие правила.

Последние легко гуглятся на:
- ИТС
- https://1c-syntax.github.io/bsl-language-server/diagnostics/
- https://refactoring.guru
- https://refactoring.com/catalog/
- и других общепринятых ресурсах

Это позволит вам вырасти по грейдам, на примере ожиданий одного работодателя https://habr.com/ru/company/skyeng/blog/667740/

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

Лучше корректировать архитектурные решения и подсвечивать проблемы текущей реализации, а не code style - для этого есть Phoenix BSL ;)
Прикрепленные файлы:
Altez; dvsidelnikov; json; cleaner_it; Petr54-ru; unichkin; +6 Ответить
70. DELOVOYDOM 14.02.24 14:16 Сейчас в теме
(14) Корректировать архитектурные решения когда уже за годы скопилась армия пользователей на плохом решении... собственники не хотят этим заниматься - приносит деньги и хорошо. Набрасывают исполнители код сверху.
Представляется правильным выпуск нового продукта с возможностью интеграции со старым либо переносом данных. Тема архитектуры ПО в 1С почти не обсуждается. Поэтому большинство разработок в 1С это вырвиглаз с множеством таблиц полей кнопок вкладок в одной форме
15. SergeyPZU 23 03.06.22 07:40 Сейчас в теме
7. Для отладки текста запроса код модуля не нужен, но для отладки кода модуля может понадобиться текст запроса. А при изменении текста запроса нужно будет проверять а не используется ли он где то ещё. Да, проверить это недолго, но все ж лишнее ненужное действие. В каких то случаях может быть и можно так красоту навести, но идея превращать это в правило - сомнительна.
unknown181538; zqzq; mrChOP93; enoty200shtyk; +4 Ответить
16. ksely 113 03.06.22 07:45 Сейчас в теме
Я бы еще добавил:

1. Функция, возвращающая какой-либо объект, всегда возвращает только один тип объекта, либо Неопределено.
2. Функция, возвращающая любую коллекцию, всегда возвращает коллекцию, пусть даже пустую. Такая функция не должна возвращать Неопределено, или объект.
3. Блок Исключение в блоке Попытка никогда не должен быть пустым. Там нужно либо логировать ошибку, либо выводить сообщение. В редких случаях, когда там точно ничего не нужно делать, там надо оставить об этом комментарий.
kaaasteeen; begemot; SerVer1C; TimofeySin; pavlov_dv; +5 Ответить
19. TimofeySin 172 03.06.22 10:08 Сейчас в теме
(16)
нужно
По первым двум пунктам ДА. По 3-ему не всегда это нужно, другой вариант, что часто, когда это нужно, этого не делают :))
unknown181538; +1 Ответить
33. Asmody 06.06.22 09:58 Сейчас в теме
(16) Я допускаю возвращение Неопределено из функции в случае, если пустая коллекция является одним из нормальных ожидаемых результатов функции. В этом случае результат Неопределено показывает некорректную ситуацию типа "не шмогла".
45. Iscarimet 06.06.22 18:43 Сейчас в теме
(33) Если функция возвращает только коллекцию, то проверить результат на пустоту очень просто:
Если РезультатФункции.Количество() = 0 Тогда

Если функция может вернуть как коллекцию, так и Неопределено, то проверка будет двухступенчатой:
1. Проверка на Неопределено, например:
Если РезультатФункции <> Неопределено Тогда

2. Проверка на пустую коллекцию:
Если РезультатФункции.Количество() = 0 Тогда


P.S. Справедливости ради можно сказать, что проверка на пустую коллекцию не всегда нужна. Потому что обычно коллекцию обходят циклом, или используют ЗаполнитьЗначенияСвойств() и другие варианты.
Риник; ejijoka; +2 Ответить
46. Asmody 06.06.22 23:22 Сейчас в теме
(45) читайте внимательно: "если пустая коллекция является одним из нормальных ожидаемых результатов функции"
в этом случае Неопределено мы возвращаем как "ненормальный" результат.
Платформа тоже так делает в некоторых случаях, если что
Риник; +1 Ответить
47. Iscarimet 07.06.22 05:59 Сейчас в теме
(46) ок, с этим согласен.
Я в случаях, когда внутри функции может что-то сломаться, формирую структуру:
Результат = Новый Структура;
Результат.Вставить("Успешно", Ложь);
Результат.Вставить("Коллекция", Новый Массив); // это и есть коллекция с данными, ключ выбирается по месту
Результат.Вставить("ТекстОшибки", "");

Так я гарантирую, что на выходе функции точно будет строго определенная коллекция. И не надо обрабатывать другие типы.
23. klaus38 03.06.22 19:46 Сейчас в теме
Знал что в седьмом пункте, нет смысла в примере кода, но все равно под сполер заглянул)
26. ixijixi 1833 04.06.22 10:20 Сейчас в теме
Я буду употреблять слово «Функция», но под этим буду иметь в виду «Функции» и «Процедуры»

Я не использую процедуры от слова совсем, только функции. Оставляю только те процедуры, что конструктор платформы создает сам. Функция не обязательно должна что-то возвращать (по умолчанию это будет Неопределено), но если мне впоследствии нужно будет что-то вернуть, я с лёгкостью это изменю, не перелопачивая код.
Возможно это не соответствует стандартам, но это удобно.
0x00; ejijoka; +2 1 Ответить
27. unichkin 1572 04.06.22 12:48 Сейчас в теме
0) Я буду употреблять слово «Функция», но под этим буду иметь в виду «Функции» и «Процедуры». - удобнее употреблять термин "метод"

1) Объекты следует заполнять используя события обработки заполнения.
Плохо: Документы.РеализацияТоваровУслуг.ЗаполнитьДокументРеализации(РеализацияТоваровОбъект,ДанныеЗаполнения);
Хорошо: РеализацияТоваровОбъект.Заполнить(ДанныеЗаполнения)
Почему: Это выделяет код, ответственный конкретно за заполнение объекта, позволяет его унифицировать. Эта же рекомендация есть в стандартах: https://its.1c.ru/db/v8std#content:396:hdoc

4) В общем случае - от глагола (инфинитива) образуются именования процедур (надо что-то сделать). Имена функций от сути происходящего в ней. Если функция является по своей сути процедурой, допустимо ее также именовать от глагола. Например "ВыполнитьЗаписьОбъектов", возвращающая результат записи. Булево, или конструктор в виде структуры с описанием. Не следует в функциях употреблять слова "Вернуть", "Получить" и т.д. - и так понятно что функция нужна для того чтобы что-то вернуть \ получить. Подробнее см. https://its.1c.ru/db/v8std#content:647:hdoc

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

6) См. https://its.1c.ru/db/v8std#content:456:hdoc, п.4. Сможете поставить точку останова на операторе "Возврат"? Не надо говорить что "там все просто, и это никогда не понадобится". Понадобится. Причем в проде, на пике сдачи регл. отчетности.

10, 11) https://its.1c.ru/db/v8std#content:453:hdoc


15) Это называется "единая точка выхода". В процедурах - чем выше возврат, тем лучше. В функциях он всегда должен быть один, в конце метода. Если этого сложно добиться, значит метод надо рефакторить.

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

// Было:
Функция Хорошо()	
	РеализацияСсылка = Документы.РеализацияТоваровУслуг.НайтиДокумент();
	СтруктураВозврата = Новый Структура;
	Если ЗначениеЗаполнено(РеализацияСсылка) Тогда
		СтруктураВозврата.Вставить("Документ",РеализацияСсылка);
		СтруктураВозврата.Вставить("Ошибка",Ложь);
	Иначе		
		СтруктураВозврата.Вставить("Документ",Неопределено);
		СтруктураВозврата.Вставить("Ошибка",Истина);		
	КонецЕсли;	
	
	Возврат СтруктураВозврата;
КонецФункции

// Стало:

Функция РезультатПоискаРеализации()	
	Результат = НовоеОписаниеРезультатаПоискаДокумента();
	Результат.Документ = Документы.РеализацияТоваровУслуг.НайтиДокумент();
	Результат.Ошибка = НЕ ЗначениеЗаполнено(Результат.Документ);
	
	Возврат Результат;
КонецФункции

Функция НовоеОписаниеРезультатаПоискаДокумента()
	Результат = Новый Структура;
	Результат.Вставить("Документ");
	Результат.Вставить("Ошибка", Ложь);
	
	Возврат Результат;
КонецФункции
Показать
Detache; zqzq; t278; kalyaka; begemot; DrAku1a; +6 Ответить
34. Asmody 06.06.22 10:07 Сейчас в теме
(27)
В функциях он всегда должен быть один, в конце метода.

Ну тоже же холиварное утверждение.

Если функция - это один Если ... Тогда <много кода> Иначе <одна строка> КонецЕсли, то почему сразу не срубить короткий конец?
Риник; +1 Ответить
36. unichkin 1572 06.06.22 11:16 Сейчас в теме
(34) Я сторонник утверждения Мартина что у метода есть два правила - он во-первых должен быть коротким, а во-вторых еще короче. Поэтому если есть "Если ... многокода", то часть с "МногоКода" надо вынести в метод. Следуя этому принципу как-то само собой так выходит что Возврат можно оставлять всегда в конце. Неудобно считывать функцию с большим телом, посередине которого есть возвраты. Лучше соблюдать принцип единой точки выхода, это гарантированно уменьшит сложность и как следствие риски ошибок.
DELOVOYDOM; +1 Ответить
38. Asmody 06.06.22 11:48 Сейчас в теме
(36) я использовал "многоКода" это только для противопоставления с "малоКода". Ну, типа 1 строка и ... 7 строк.
Меня вот от "Иначе" коробит, даже если я вижу где-то слегка выше соответствующий "Если" .
(А ещё 1Ска не умеет сворачивать "Если" до "Иначе")
28. DrAku1a 1732 04.06.22 12:54 Сейчас в теме
Процедура Хорошо()
	Ошибка = Ложь;       
	ОписаниеОшибки = "";
	
	Попытка
		Документ.Записать();  
	Исключение           
		ОписаниеОшибки = ОписаниеОшибки();
		Ошибка = Истина;
	КонецПопытки;
	
	Если НЕ Ошибка Тогда
		Сообщить("Всё хорошо");
	Иначе
		Сообщить(ОписаниеОшибки);	
	КонецЕсли;	
	
КонецПроцедуры
Показать
А не лучше ли назвать тогда переменную "НетОшибок", присвоить ей изначально Истина, а при ошибке присваивать Ложь, и не использовать оператор НЕ?

+ По поводу 6. все уже высказались. Добавлю: Вариант написания в строку плохо читается!
Вообще, код в одну строку - это плохой стиль.
Процедура Плохо(Документ)
	
	МояСтруктура = новый Структура("ДокДата,ДокНомер,ДокСсылка,ДокПримечание", Документ.Дата, Документ.Номер, Документ.Ссылка, Документ.Примечание);
	
КонецПроцедуры

Процедура Хорошо(Документ)
	
	МояСтруктура = новый Структура;
	МояСтруктура.Вставить("ДокДата",       Документ.Дата);
	МояСтруктура.Вставить("ДокНомер",      Документ.Номер);
	МояСтруктура.Вставить("ДокСсылка",     Документ.Ссылка);
	МояСтруктура.Вставить("ДокПримечание", Документ.Примечание);
	
КонецПроцедуры
Показать
29. unichkin 1572 04.06.22 13:01 Сейчас в теме
(28)
НетОшибок

Считаю, всеми силами надо избегать обратных условий. При невозможности обойтись - искать синонимы. Например надо добавить параметр учетной политики "НеИспользоватьФункционал". Кажется, что его удобнее задать именно так, т.к. по умолчанию будет Ложь, и не надо перезаполнять документы. Но потом начинается кошмар в коде... Лучше либо описать прямо: ИспользоватьФункционал, и добавить обработчик обновления, который взведет флаг в Истина в существующих документах (учетных политик не так много, на самом деле). Либо найти синоним, например "ИсключитьИспользованиеФункционала".
При наборе кода, при описании ФТ, при вводе реквизита и т.д..
Иначе при дальнейшем развитии и усложнении кода начинаются игры разума с "НЕ НетОшибок". И вместо того чтобы работать приходится маяться такой фигней, соображать что будет при расчете.
enoty200shtyk; FatPanzer; begemot; LeXXeR; zadoy; DrAku1a; +6 Ответить
31. milestone_is 06.06.22 05:57 Сейчас в теме
Пипец. Холиварный. Чел открыл для себя троицу: Мартина Фаулера "Рефакторинг", Стива МакКоннелла "Совершенный код", Роберта Мартина "Чистый код". До чего мир скатился! И кого только в программисты берут?!

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

Что там в тригонометрии?! sin 2а = 2 * sin a * cos a. Хочешь, вынеси в процедуру получение синуса, а косинус вырази через него. А если бизнес-логика того потребует, то вырази всё через тангенс половинного аргумента или ряды и вперед.

Пункт 11 - я сейчас в автора тапком кину... А точнее говоря, это явный признак того, что функцию-процедуру не разложили на множители (Фаулер), оттого и входящих параметров много (Фаулер), то есть [бизнес-]логика не разграничена (Фаулер), значит нарушен пункт 1 (Фаулер).
Пункт 15 - классика жанра в конце текста. Видимо, автор в своей практике видел и так, а видел и так. А как нужно - автор не до конца понимает, или не решил для себя, или уже устал и пунктов много. Поэтому используются обтекаемые фразы "стараться" (со смыслом, "я не понимаю, но делаю" с мемом "Давай, программировай!") и "если функция этого допускает" (со смыслом, "не виноватая я, функция сама"), дающие на откуп самого программиста: хочешь - пиши так, а хочешь - как сказал стажер-с-5-летним-стажем ("сеньор" типа). Ответ-то простой - см. пункт 1, а точнее троицу Фаулера-Макконнелла-Мартина.
ejijoka; zqzq; Petr54-ru; +3 1 Ответить
49. zqzq 25 07.06.22 09:37 Сейчас в теме
(31)
Пункт 11 - я сейчас в автора тапком кину... А точнее говоря, это явный признак того, что функцию-процедуру не разложили на множители (Фаулер), оттого и входящих параметров много (Фаулер), то есть [бизнес-]логика не разграничена (Фаулер), значит нарушен пункт 1 (Фаулер).
Абсолютно согласен, всегда избегаю структур в параметрах. Как будто количество параметров реально уменьшится, если запихать всё в структуру.
Но 1С сами такой подход продвигают, из-за отсутствия ООП. Этакие квази-объекты в структурах.
pavlov_dv; json; ejijoka; +3 1 Ответить
59. unichkin 1572 18.06.22 13:53 Сейчас в теме
(49) А если перечень параметров будет меняться? А если первый параметр понадобится сделать с передачей значения?
Было:

МояФункция(Дата, Организация)

Стало

МояФункция(Дата = Неопределено, Организация)

Указание структуры - это весьма удобный подход, сокращающий риски рефакторинга. Самый надежный метод - который принимает внутрь структуру, и отдает структуру. Причем, если это экспортный метод - он должен принимать и отдавать конструктор.

// Плохо:

Функция ОписаниеЗадолженности(Дата, Организация, Контрагент) Экспорт
		
КонецФункции

// Хорошо

Функция НовыеПараметрыПолученияЗадолженности() Экспорт
	Результат = Новый Структура;
	Результат.Вставить("Дата");
	Результат.Вставить("Организация");
	Результат.Вставить("Контрагент");
	
	Возврат Результат;
	
КонецФункции 

Функция НовыйРезультатПолученияЗадолженности() Экспорт
	
	Результат = Новый Структура;
	Результат.Вставить("Суммы");
	Результат.Вставить("ЕстьОшибка", Ложь);
	Результат.Вставить("Описание", "");
	
	Возврат Результат;
	
КонецФункции 

Функция ОписаниеЗадолженности(ПараметрыПолучения) Экспорт
	Результат = НовыйРезультатПолученияЗадолженности();
	// Много кода
	Возврат Результат;	
КонецФункции

// Пример использования при локальном вызове:

Функция СуммыЗадолженности()
	
	ОписаниеЗадолженности = ОбщийМодуль.НовыйРезультатПолученияЗадолженности();
	Попытка
		ПараметрыПолучения = ОбщийМодуль.НовыеПараметрыПолученияЗадолженности();
		ОписаниеЗадолженности = ОбщийМодуль.ОписаниеЗадолженности(ПараметрыПолучения);
		
	Исключение
	    ОписаниеОшибки = ОписаниеОшибки();
		// Запись в ЖР
	КонецПопытки;
	
	Результат = ОписаниеЗадолженности.Суммы;
	Возврат Результат;
	
КонецФункции
 
Показать
60. zqzq 25 20.06.22 13:22 Сейчас в теме
(59) Мне лично удобнее вызвать
МояФункция( , Организация)
чем ловить ошибки времени выполнения из-за опечатки в ключе структуры.
+ Много лишнего (служебного) кода со структурами.

При добавлении нового параметра нужно или прописать ему значение по умолчанию или изменить все вызовы функции. Структура тут ничем не поможет (по сути то же значение по умолчанию).

Параметры и выход функции описываются в комментарии к ней.

По выходному результату тут есть 2 пути: отдавать структуру из функции или в процедуру принимать пустые параметры для изменения.
71. DELOVOYDOM 14.02.24 14:44 Сейчас в теме
(31) бизнес логику пожалуйста оставьте серьезным дядям, зарабатывающим большие деньги, а именно инструментам BPMN и им подобным. Программист не должен подменять кодом бизнес логику (надеюсь никого не обидел) и не может качественно подменить. Если бизнес-логика микрохирургия, или юриспруденция - не надо диктовать кодом, как работать врачу или адвокату. Код должен выполнять технические функции, не надо городить франкенштейна, закладывая в модули логику бизнеса. Код нужен для создания инструментов для бизнеса, а не для управления через код бизнесом. Но это больше тема для руководителей. Программистов надо ставить в четкие рамки своей компетенции и не позволять решать в коде в какой последовательности отгружать товар или закрывать рабочие смены.
Тут кто-то написал в комментариях - а зачем мне писать комменты помогать другому программисту? Все верно, как правило программисты не заинтересованы в качественной архитектуре, они заинтересованы в своей востребованности, зависимости работодателя от него и хорошем заработке. А хорошая архитектура - это опасность для такого деятеля.
Заказчик или работодатель в идеале не должен рассказывать программисту свою бизнес-логику, достаточно объектов предметной области, а что с ними делать давайте специалисты уже сами разберутся - адвокаты юристы врачи. Разработчик пусть отвечает только за технический функционал программы - кнопки таблички формы свойства. С логикой в качественном пользовательском интерфейсе с возможностью автоматизации бизнес-процессов специалисты предметной области разберутся сами. Мало того, такой подход позволит в пользовательском операционном режиме совершенствовать эту самую логику без помощи программистов
32. avbolshakov 06.06.22 07:51 Сейчас в теме
немного оффтопик про "НЕ ЗначениеЗаполнено(РеализацияТоваровСсылка)". Я думал, что если известен тип, то быстрее будет сравнивать с пустой ссылкой, те "РеализацияТоваровСсылка = Документы.РеализацияТоваров.ПустаяСсылка()".
37. unichkin 1572 06.06.22 11:19 Сейчас в теме
(32) Нет, это заблуждение. Всегда есть вероятность что поисковый метод вернет Null, или Неопределено. Кстати, к слову - метод ссылки "Пустая" тоже применять не стоит, поскольку реквизит при развитии программы может стать составного типа. Когда-то было инф. письмо от 1С что появился новый метод ЗначениеЗаполнено, и методы "Пустая" для ссылки, ПустаяСтрока - устаревшие, и оставлены для совместимости.
zqzq; avbolshakov; +2 Ответить
54. unknown181538 158 16.06.22 12:36 Сейчас в теме
(37) А я подцепил это на курсах в УЦ 1с, где сказали, что Пустая() работает быстрее. Хотя понятно, что это не значимая величина, но срабатывает часто идея максимальной оптимизации без доп. затра.
55. unichkin 1572 16.06.22 13:00 Сейчас в теме
(54) Нет в них существенной разницы, это флуктуации.
Я тоже когда-то упирался против использования ЗначениеЗаполнено, с некоторым стыдом предлагаю ознакомиться с этой темой на мисте https://forum.mista.ru/topic.php?id=793824, начиная с поста 15.
Умные люди мне говорили, я не слушал. Потом сам же к этим выводам и пришел.
56. unknown181538 158 16.06.22 13:05 Сейчас в теме
(55) Спасибо. я использую пустая() или пустаяСтрока, когда тип точно определен. Например, сразу после метода НайтиПоНаименованию() . В этом случае, разницы не вижу.
57. unichkin 1572 16.06.22 13:58 Сейчас в теме
(56) Вот-вот, мое рассуждение из той самой темы.... Проблема в том, что любой реквизит внезапно может стать составным. НайтиПоНаименованию - внезапно может вернуть неопределено, если кто-то обнулил наименование. И т.д. и т.п.
Потом приходит понимание, что такие вот места далее ручным поиском не найдешь. И остается "отлаживаться на хомячках", выслушивая претензии в свой адрес. В общем, не буду больше ничего говорить - знаю все ответные аргументы, некогда мыслил примерно также. Это видимо тот случай, когда надо самому вынимать палки из колес, и к этому приходить.
58. unknown181538 158 16.06.22 14:04 Сейчас в теме
(57) ну, спорить желания не имею, т.к. сам не являюсь каким-то адептом метода ПустаяСсылка(), и эта тема не вызывает у меня желания на чем-то настаивать, очень уж не заряжена эмоционально :)
Но справедливости ради, если у вас кто-то длину наименования обнулит, то метод ЗначениеЗаполнено() вас в этом случае не спасет, а скорее наоборот скроет ошибку. Но это все детали из гипотетического мира.
35. TimofeySin 172 06.06.22 10:49 Сейчас в теме
Маленький дисклеймер:
Я читал Фаулера-Макконнелла-Мартина и даже рекомендации 1С. Но я устал копаться в кое как написаном коде других программистов. Видимо им не охото читать книжки про стили программирования, поэтому вывел эти короткие и понятные правила. Может говнокода хоть на 1% будет меньше.
abasovit; triviumfan; avbolshakov; +3 Ответить
39. Petr54-ru 92 06.06.22 14:15 Сейчас в теме
(35)
Маленький дисклеймер:
Я читал Фаулера-Макконнелла-Мартина и даже рекомендации 1С. Но я устал копаться в кое как написаном коде других программистов. Видимо им не охото читать книжки про стили программирования, поэтому вывел эти короткие и понятные правила. Может говнокода хоть на 1% будет меньше.


А не надо стесняться говонокода.

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

Я стараюсь придерживаться стандартов кодирования, изложенных на ИТС.
Я всегда в комментариях стараюсь описать бизнес логику - чтобы потом было о чем говорить с заказчиком.
Я оставляю старый код закомментированным - зеленые поля меня не напрягают - но если что я моментально выполнить * ,если заказчик это решит.
50. TimofeySin 172 07.06.22 10:05 Сейчас в теме
(39)
Самые разные, вообще никакого отношения к качеству кода не имеющие. Про рефакторинг когда и технический долг можно не напрягаясь говорить с заказчиком - все равно если все

Есть такое понятие "культура производства", которую надо соблюдать, что и подтверждается вашими словами, что ваш код выкинут на помойку. Я в 1С уже чуть более 13 лет, и что самое удивительное, некоторый который я написал уже около 7-8 лет назад, еще не выкинули.
Надо уважать себя и уважать программистов, которые будут разбираться в коде, которого вы не стестняетесь. И это только моральный аспект. Но есть еще и скорость отладки, внесения изменений итд
abasovit; kalyaka; unichkin; +3 Ответить
52. Petr54-ru 92 07.06.22 11:44 Сейчас в теме
(50)
Есть такое понятие "культура производства", которую надо соблюдать, что и подтверждается вашими словами, что ваш код выкинут на помойку. Я в 1С уже чуть более 13 лет, и что самое удивительное, некоторый который я написал уже около 7-8 лет назад, еще не выкинули.
Я же про это писал - остальной то код на помойке, и это соотносится в районе 80-20 - привет правилу Парето. Если с этими "долгоиграющими" 20% что нибудь нужно будет делать, тогда и будет смысл упираться рогом.

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


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


Чем бы 1С программист на работе не занимался в любом случае это будет - решение задач бизнеса, в интересах бизнеса. Как говорят америанцы, - "когда человек спрашивает в магазине сверло на четверть дюйма, ему не нужно сверло - ему нужны отверстия диаметром четверть дюйма". Бизнесу нужно решение - в минимально возможные сроки и за минимальные деньги - что там будет внутри - бизнесу без разницы. С моей колокольни ваша позиция - "Надо уважать себя и уважать программистов, которые будут разбираться в коде, которого вы не стестняетесь" - это называется ставить свои личные амбиции выше интересов дела, как здесь насчет "морального аспекта".

Мне вообще глубоко безразличны программисты, которые будут разбираться в моем коде. Стараюсь придерживаться стандартов разработки фирмы 1СДля себя, как я уже выше писал, я там оставляю комментарии, в которой описываю бизнес логику - чего именно в тот раз желал заказчик. Точно так же я отношусь к программистам, чей код мне приходится допиливать - если я подписался выполнить задачу, то я обязан эту задачу выполнить, больше тут обсуждать нечего. Как писали классики - "Не надо делать из еды культа"

Бизнесу от нас не нужно стремление к идеалу за его счет - ему нужно просто работающее решение. Как в известном меме автоматизаторов - "теперь девушка-оператор сможет раскладывать на три пасьянса больше".
40. Hans 3 06.06.22 14:19 Сейчас в теме
Дешайтанизация кода.
user803412; +1 Ответить
41. Hans 3 06.06.22 14:22 Сейчас в теме
В функциях первой объявленной переменной надо объявлять то, что будет возвращаться. Что бы не крутить до конца, что бы узнать какая переменная возвращается.
51. Asmody 07.06.22 10:36 Сейчас в теме
Почитаешь на форумах - все такие правильные, книжки умные читают, слова красивые знают.
А откроешь какой-нибудь модуль типовой или не очень - мама дорогая! Чужие для хищников писали, не иначе!
abasovit; altu71; ivanov660; ediks; brake71; +5 Ответить
72. DELOVOYDOM 14.02.24 14:54 Сейчас в теме
(51) Сейчас опять меня заминусуют) На платформе 1С можно создавать шикарные решения с модным интерфейсом и мы под себя это делаем. Но большинство, да почти 99% разработок, это вырвиглаз. И что этот красивый код, если сами решения отвратительные ужасные и пользователи стонут? Где архитекторы интерфейса? Где все комментаторы, которые считают себя умными, но их продукты это слезы из глаз с нагромождением различных элементов на форме и кнопок из прошлого века? Где флэт интерфейс, интуитивная навигация и минимализм? Я это к тому, что большинство книг статей и рекомендаций равны нулю, если конечный итог весь этот ужас на рынке решений 1с, который выкатывают программисты несмотря на то, что на платформе 1с можно творить чудеса.
61. user1342811 18 21.06.22 15:01 Сейчас в теме
Не нравится мне пример в 6 пункте, а именно, два возврата. Мое мнение два возврата возможны когда есть какое-то условие которое известно в самом начале и весь последующий код становиться не нужным тогда можно написать:
Если Отказ Тогда
      Возврат;
КонецЕсли;
КакойтоКодВычисляющийРезультат;
Возврат Результат;

По-моему лучше присвоить значение переменной значение, а потом уже её вернуть.
IMHO, что в примере плохо, должно быть хорошо и наоборот.
62. RocKeR_13 1345 22.06.22 13:26 Сейчас в теме
Ситуация, обратная п.14 и частично касающаяся п.11: инициализацию структуры параметров для некоторой процедуры/функции выносите в отдельную функцию. В типовых конфигурациях данная рекомендация хорошо прослеживается в общих клиент/серверных модулях. Очень актуально, например, при реализации доступа к некоторому API, когда все запросы выполняются единой процедурой/функцией: не нужно для каждого метода писать отдельную инициализацию параметров, запоминая при этом, какое имя параметра использовалось уже для логина, какое для заголовков и т.п. Ну и, понятно, снижает количество строк кода.
63. JOJ73 23.06.22 14:09 Сейчас в теме
п.9
......
//-- Начало 19 октября 2022 года

Смешно ))
64. Snouphruh 19.07.22 11:04 Сейчас в теме
7. если мне необходимо запросом получить какие-то данные, то я пишу функцию, например:

&НаСервереБезКонтекста
Функция ПолучитьСписокДокументовНаСервере (СтрокаИмениДокумента, СтруктураПараметров = Неопределено)

	#Если Сервер И Не Сервер Тогда
		СтруктураПараметров = Новый Структура;
	#КонецЕсли

	#Область	запрос
	зпрДанные = Новый Запрос ("

	|	ВЫБРАТЬ РАЗРЕШЕННЫЕ
	|		Ссылка	Объект
	|	ИЗ
	|		&Документ
	|	ГДЕ
	|		ИСТИНА
	|	//УСЛОВИЕ_Проведен

	|	");
	#КонецОбласти // запрос

	зпрДанные.Текст = СтрЗаменить (зпрДанные.Текст, "&Документ", "Документ." + СтрокаИмениДокумента);

	Если СтруктураПараметров <> Неопределено Тогда
		Если СтруктураПараметров.Свойство ("Проведен") Тогда
			зпрДанные.Текст = СтрЗаменить (зпрДанные.Текст, "//УСЛОВИЕ_Проведен", "И	" + ? (СтруктураПараметров.Проведен, "", "НЕ	") + Проведен);
		КонецЕсли;
	КонецЕсли;

	реззпрДанные = зпрДанные.Выполнить ();
	Если реззпрДанные.Пустой () Тогда	Возврат Неопределено	КонецЕсли;

	Возврат реззпрДанные.Выгрузить ().ВыгрузитьКолонку ("Объект");

КонецФункции // ПолучитьСписокДокументовНаСервере ()
Показать


и где-нибудь в коде, где вызываю эту функцию, я пишу:
&НаСервереБезКонтекста
Функция ПолучитьОшибкуНаСервере (СтрокаТекстаОшибки)
	Возврат Новый Структура ("Ошибка, ТекстОшибки", Истина, СтрокаТекстаОшибки);
КонецФункции // ПолучитьОшибкуНаСервере ()

&НаСервереБезКонтекста
Функция ПолучитьРезультатНаСервере (Данные = Неопределено)
	Возврат Новый Структура ("Ошибка, Данные", Ложь, Данные);
КонецФункции // ПолучитьРезультатНаСервере ()

&НаСервереБезКонтекста
Функция ОбработатьДокументыНаСервере (СтрокаИмениДокумента, СтруктураПараметров)

	мсвОбъекты = ПолучитьСписокДокументовНаСервере (СтрокаИмениДокумента, СтруктураПараметров);
	Если мсвОбъекты = Неопределено Тогда	Возврат ПолучитьОшибкуНаСервере ("Нет документов")	КонецЕсли;

	Для Каждого элмсвОбъект Из мсвОбъекты Цикл
		//…
	КонецЦикла;

	Возврат ПолучитьРезультатНаСервере ();

КонецФункции // ОбработатьДокументыНаСервере ()

…

	сттРезультат = ОбработатьДокументыНаСервере ("ПриходныйКассовыйОрдер", Новый Структура ("Проведен", Истина));
	Если сттРезультат.Ошибка Тогда
		...
	КонецЕсли;


Показать
65. Риник 14 13.12.22 01:34 Сейчас в теме
(64) только вот называть функцию Получить... -- неправильно
https://its.1c.ru/db/v8std#content:647:hdoc

С инфинитива в общем случае должны начинаться имена процедур, а не функций. А функции лучше называть так, как-будто в названии уже зашит результат, то есть не ПолучитьСписокДокументовНаСервере, а просто СписокДокументов. В коде с этой функцией может работать как с обычной переменной
66. Snouphruh 13.12.22 11:01 Сейчас в теме
(65) я пришЁл в «мир» 1С из «мира» С языка. поэтому мои функции и процедуры начинаются с глагола. в этот глагол я закладываю некий смысл результата действий той или иной функции или процедуры.
я и переменные называю тоже по-своему. например, вместо «ТоварСсылка» пишу «спрслкТовар». в префиксе я как бы указываю тип данных, который в переменной хранится. если назвать переменную, например, «СписокТоваров», то непонятно будет, что именно в такой переменной хранится (массив, список значений, таблица значений или что-то другое).

не нужно слепо следовать «правилам», которые придумали другие программисты (Фирма 1С). определЁнно, в этих правилах есть свои полезные моменты, которые полезно будет перенять, но делать только так, как там сказано, не стоит.
цель всех этих «правил» заставить программистов писать одинаково, чтоб код был одинаково всем понятен. вроде бы полезная и хорошая идея, но!!! есть побочный момент, который я считаю очень существенным, - подобные «правила» заставляют программистов мыслить и думать одинаково, то есть лишают программиста индивидуального мышления, которое приводит к уникальным решениям и подходам их реализации.
67. TimofeySin 172 13.12.22 11:10 Сейчас в теме
(66)
есть побочный момент, который я считаю очень существенным, - подобные «правила» заставляют программистов мыслить и думать одинаково, то есть лишают программиста индивидуального мышления, которое приводит к уникальным решениям

Гибкость реализации функционала ни как не коррелирует с именованием, а вот поддержка кода, очень даже. Я встречал код, где было ОбщийМодуль1-ОбщийМодуль6, программист вообще не парился про именование :).
PS по мне идея очень не плохая:
(65)
то есть не ПолучитьСписокДокументовНаСервере, а просто СписокДокументов. В коде с этой функцией может работать как с обычной переменной

Но я не люблю как-то обрабатывать результат функции не поместив его в переменную.
68. user1950534 01.12.23 15:51 Сейчас в теме
Еще возврат значений через параметры процедуры (и особенно функции) - зло зло зло!!!

Даешь Знач Параметр1, Знач Параметр2 - всегда!
Оставьте свое сообщение