Логические выражения и красивый код

20.04.19

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

В данной статье я хочу поделиться своей практикой применения логических выражений при написании кода. Учитывая тот факт, что платформа 1С 8.х использует сокращенный цикл вычисления логических выражений, можно заменить громоздкие конструкции “Если Тогда ИначеЕсли КонецЕсли” на красивую и лаконичную запись, похожую на список операций.

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

Любое выражение, написанное в коде вычисляется слева направо и согласно приоритету операторов. При вычислении логических выражений приоритет операторов следующий (в порядке убывания):

  • Операции сравнения (=, >, <, <>)

  • НЕ

  • И

  • ИЛИ

Три логических оператора: НЕ И ИЛИ для удобства понимания можно представить как арифметические: унарный минус, умножить, плюс (соответственно). Например, если мы хотим посчитать сумму покупок: 5 яблок по 12 рублей, 3 килограмма гречки по 50 рублей, 2 рулона туалетной бумаги по 25 рублей - запишем в калькулятор все это одной строкой в естественном порядке и без всяких скобок: 5 * 12 + 3 * 50 + 2 * 25. Ведь еще в школе нас научили, что сначала множим, потом плюсуем. Так и здесь мы сначала получим сумму каждой позиции, а затем общую сумму.

Аналогично работает приоритет в логическом выражении. Сначала будут вычислены все И, затем все ИЛИ. Раньше всех применится НЕ, оно инвертирует результат выражения справа от себя, аналогично унарному минусу: -5 - это как 5 только в другую сторону от нуля).

Операторы И и ИЛИ являются бинарными, то есть сравнивают 2 выражения слева и справа от себя и возвращают результат сравнения: Истина или Ложь. Цепочка операторов обрабатывается слева направо. При этом работает сокращенный цикл вычисления логических выражений. Такую фишку добавили в платформе 1с 8. В учебнике по javascript я вычитал замечательную аллегорию на этот механизм:

"Оператор И спотыкается на лжи, а оператор ИЛИ спотыкается на правде”.

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

А теперь практический пример.

Рассмотрим задачу загрузки элемента справочника “Номенклатура” из внешнего источника. Алгоритм действия примерно такой:

  • Создать карточку номенклатуры

  • Создать единицы измерения

  • Записать базовую единицу измерения в карточку номенклатуры

  • Загрузить штрихкоды номенклатуры

  • Загрузить цены номенклатуры.

Простой линейный алгоритм. При этом выполняться он должен именно в этой последовательности. И кроме того должен прерываться, если очередной этап выдал сбой. При этом желательно в конце вернуть общий результат выполнения операции. Мы можем оформить каждый этап в отдельную функцию, которая в зависимости от успешности возвращает Истину или Ложь, а затем написать следующий код:

Если НЕ СоздатьКарточкуНоменклатуры() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ СоздатьЕдиницыИзмерения() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗаписатьБазовуюЕдиницу() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗагрузитьШтрихкоды() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗагрузитьЦены() Тогда
   Возврат Ложь;
КонецЕсли;

Возврат Истина;

 

 

Вроде получилось наглядно и понятно. Но смущает часто повторяющиеся блоки Если Тогда КонецЕсли. Теперь вспомним теорию: как себя ведет цепочка И при вычислении, и перепишем код следующим образом:

Возврат СоздатьКарточкуНоменклатуры()
	И СоздатьЕдиницыИзмерения()
	И ЗаписатьБазовуюЕдиницуИзмерения()
	И ЗагрузитьШтрикоды()
	И ЗагрузитьЦены();

 

 

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

 

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

  • Создать карточку номенклатуры

  • Создать единицы измерения

  • Записать базовую единицу измерения

  • Создать характеристики

  • Загрузить коды весового товара

  • Загрузить штрикоды

  • Загрузить цены

Алгоритм перестал быть линейным. Набор операций теперь зависит от флагов: ИспользуютсяХарактеристики и ВесовойТовар. Попробуем записать этот алгоритм в одну строчку:

Возврат СоздатьКатрочкуНоменклатуры()
	И СоздатьЕдиницыИзмерения()
	И ЗаписатьБазовуюЕдиницуИзмерения()
	И (НЕ ИспользуютяХарактеристики ИЛИ СоздатьХарактеристики())
	И (НЕ ВесовойТовар ИЛИ ЗагрузитьКодыВесовогоТовара())
	И ЗагрузитьШтрихкоды()
	И ЗагрузитьЦены();

Для замены конструкции:

Если ИспользуютсяХарактеристики Тогда
	Если НЕ СоздатьХарактеристики() Тогда
		Возврат Ложь;
	КонецЕсли;
КонецЕсли;

 

 

Мы использовали конструкцию с ИЛИ. Поскольку мы помним, что ИЛИ запинается на правде, значение флага инвертировали с помощью НЕ. Такое выражение остановится на вычислении значения флага, если он не установлен либо пройдет дальше и вычислит правое выражение и создаст характеристики для товара. Поскольку приоритет ИЛИ ниже, чем И, то эту конструкцию мы заключили в скобки.

Чтобы избавиться от круглых скобок, можно перевернуть все выражение и заменить И на ИЛИ так чтобы вложенные выражения содержали конструкцию И и выполнялись согласно приоритету первыми:

Результат = НЕ СоздатьКарточкуНоменклатуры()
	ИЛИ НЕ СоздатьЕдиницыИзмерения()
	ИЛИ НЕ ЗаписатьБазовуюЕдиницуИзмерения()
	ИЛИ ИспользуютсяХарактеристики
		И НЕ СоздатьХарактеристики()
	ИЛИ ВесовойТовар
		И НЕ ЗагрузитьКодыВесовогоТовара()
	ИЛИ НЕ ЗагрузитьШтрихкоды()
	ИЛИ НЕ ЗагрузитьЦены();

Возврат НЕ Результат;

Поскольку ИЛИ запинается на правде, то для сохранения функционала мы инвертировали каждый вызов операции. Вложенное условие с конструкцией И выполняется в первую очередь, поэтому круглые скобки уже не нужны. Поскольку И запинается на Лжи, то при снятом флаге ИспользуютсяХарактеристики выражение НЕ СоздатьХарактеристики() вычисляться не будет, и соответственно характеристики не создадутся. В таком виде вложенное выражение читается естественнее. Все полученное выражение возвращает Ложь в случае успешного выполнения всех операций, поэтому значение результата в конце инвертируется. Кстати дополнительный отступ перед И визуально отделяет вложенное условие, что в условии отсутствия круглых скобок облегчает анализ кода.

Практики программирования логические выражения приоритет операторов красивый код

См. также

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

В последнее время термин «чистый код» стал очень популярным. Появились даже курсы по данной тематике. Так что же это такое?

16.09.2024    14077    markbraer    64    

39

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

В статье рассматривается отказ от использования процедур и унификация формата ответа функций. Способ описывается на примере развития абстрактной информационной системы, работающей с PDF файлами.

10.09.2024    924    acces969    4    

6

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

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

28.08.2024    1174    Chernazem    3    

6

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

SOLID – принципы проектирования программных структур (модулей). Акроним S.O.L.I.D. образован из первой буквы пяти принципов. Эти принципы делают код более гибким, упрощают разработку. Принято считать, что принципы SOLID применимы только в объектно-ориентированном программировании. Но их можно успешно использовать и в 1С. Расскажем о том, как разобраться в принципах SOLID и начать применять их при работе в 1С.

22.08.2024    10242    alex_sayan    41    

52

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

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

25.06.2024    4210    MadRave    34    

27

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

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

1 стартмани

04.06.2024    6284    mrXoxot    55    

42

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

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

10.04.2024    13377    artbear    85    

108

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

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

01.04.2024    4252    DrAku1a    15    

39
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. acanta 21.04.19 00:07 Сейчас в теме
Логика мужская, с начесом.
Я верю что когда нибудь такой код станет стандартом и войдет в бсп и все типовые конфигурации.
Алексей_mir2mb; +1 1 Ответить
2. tormozit 7230 21.04.19 07:20 Сейчас в теме
Не стоит превращать весь код и особенно логику верхнего уровня в большие логические выражения, состоящие из вызовов многих прикладных функций. Ведь
- точки останова будут работать только в первой строке каждого такого выражения
- пошаговая отладка по вызовам прикладных функций в одном выражении требует некоторой сноровки
- в платформе есть проблемы с некорректным разнесением замеров производительности по строкам многострочных выражений.
Поэтому такая красота будет совсем не бесплатной.
batyaevyug; Andry1619; user1609888; Rabot; Rafaraf; MebelVlad; user1731670; Hobbit_Jedi; m.s.moiseev; ManyakRus; json; vv2; user733289; Unk92; YanTsys; signum2009; lmnlmn; gigabyte_artur; manlak; mivari; mao_sandr13; kuzyara; Алексей_mir2mb; pparshin; abadonna83; Darklight; SlavaKron; succub1_5; AnderWonder; slavap; singlych; wolfsoft; Jeka44; CyberCerber; babys; rusmil; fancy; bashirov.rs; Yakud3a; ArchLord42; Soloist; Danila-Master; akor77; rpgshnik; tulakin_s; Oldsad; shalimski; t278; TimkoNzt; +49 Ответить
6. Vortigaunt 97 21.04.19 12:36 Сейчас в теме
(2) Спасибо. Возьму на заметку. Такой стиль я подсмотрел в проекте, который достался нашей фирме по наследству. И только недавно реализовал в своей обработке. Поэтому особо отлаживать его еще не приходилось. Мне в первую очередь понравилось как это выглядит, и как читается.
84. mity1982 10.04.21 12:43 Сейчас в теме
(2) Набрел на Ваш комментарий, оказался "в кассу". Я использую иногда "текучие" выражения типа
Конструктор.Создать(Тип)        
                    .Заполнить(Данные)
                    .Заполнить(Данные1)
                    .Записать(Настройки);

Мне такой синтаксис визуально нравится. Но как Вы верно заметили не удобно отлаживать такие "сопли". Буквально после прочтения возникла идея решения этой давно мучавшей меня проблемы - добавить константу в вызов:
Конструктор.Создать(Тип,1)
                    .Заполнить(Данные,2)
                    .Заполнить(Данные1,3)
                    .Записать(Настройки,4);


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

Проблема с тем, что могло изменится имя, набор параметров функции, но это касается только замыкания и к топику не относится.
3. vcv 89 21.04.19 08:45 Сейчас в теме
Лучше не использовать такие методы. Вы закладываете в логику кода особенности реализации ленивых вычислений. А если они изменятся? А если какая-нибудь 1С9 таки начнёт использовать многозадачность и последовательность выполнения станет неопределенной?
virina_k; gigabyte_artur; Алексей_mir2mb; pparshin; AnderWonder; Lapitskiy; +6 Ответить
5. Vortigaunt 97 21.04.19 12:21 Сейчас в теме
(3) Справедливое замечание. Я даже переспросил у Гугла, чтоб не облажаться с ответом. Логика ленивых вычислений присутствует не только у 1С, точно так же вычисляются выражения && и || в Джава и Джаваскрипт. Не проверял, но скорее всего у других языков тоже такое есть. Похоже, что это уже стандарт и предпосылок к его изменению я не вижу.
Насчет многопоточности. Я думаю, что если в новой платформе включат многопоточность, то это в коде должно как-то по особенному отражаться. Либо какой-то особый признак у модуля, либо особые директивы препроцессора типа &НаКлиентеАсинхронный. Если предположить что в новой платформе код будет выполняться не последовательно, а все функции будут закидываться в стек, а выполняться по принципу кто успел, тот и съел, то не только мой код сломается. Мне кажется в таких условиях любой код на 1С перестанет работать.
LosevI; Алексей_mir2mb; PLAstic; premierex; +4 Ответить
25. babys 90 22.04.19 10:06 Сейчас в теме
(5) Многопоточность уже включена, просто не все об этом знают и помнят :)
Hobbit_Jedi; +1 Ответить
36. Darklight 33 22.04.19 15:17 Сейчас в теме
(25)Если Вы про фоновые задания - то это совсем другое дело...
41. babys 90 22.04.19 17:32 Сейчас в теме
(36) А как Вы себе представляете "истинную" много поточность в 1С. Давайте там ещё и "классическое" ООП поищем :)
Как смогли так и реализовали. Исполнение параллельных вычислений есть - есть. Семафоры есть - есть. Ну а дальше "не шмогла" :)

ИМХО, всю концепцию 1С не плохо бы перетрясти. А то кусок "правого" похода, кусок "левого", и ещё до кучи пара-тройка технологий " авось кто придумает как использовать" :)

ЗЫ: Сейчас перечитал, и понял насколько у меня был узок и зашорен подход к программированию, когда я писал на C и Prolog :)
Hobbit_Jedi; +1 Ответить
42. Darklight 33 22.04.19 17:54 Сейчас в теме
(41)В том то всё и дело - что я никак не представляю многопоточность в классическом 1С :-(
И согласен с тем, что всю концепцию языка (и платформы) 1С надо перетрясти. Но, не уверен, что на это хоть когда-нибудь пойдут братья Нуралиевы. Но они не вечны (как и мы) - возможно на анонсирование принципиально иного 1С Предприятия 9 решится тот, кто придёт после них... но, как говорится, не в этой жизни :-(

Но ведь это Вы написали "Многопоточность уже включена" - а её реально-то и нет.


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

Более того - при таком подходе часть вычислений и проверок вообще, по-возможности, нужно выносить за рамки runtime - выполняя их ещё в конфигураторе, на стадии первичной компиляции (и проверки конфигурации).
43. sergathome 4 22.04.19 18:03 Сейчас в теме
(42) мне бы, например, на первых порах, хватило бы что-то типа ЗапуститьПараллельно(х) и ОжидатьИсполнения(х) без запуска фонового задания
Hobbit_Jedi; +1 Ответить
45. acanta 22.04.19 18:21 Сейчас в теме
(43) что мешает сделать это в бсп?
47. Darklight 33 22.04.19 18:24 Сейчас в теме
(45)То, что платформа не поддерживает параллеьность для пользовательского кода. ФоновыеЗадания не в счёт - это отдельные процессы, а не простые потоки - с кучей своих недостатков, ограничений и издержек, да ещё и доступные только для серверного контекста.
Hobbit_Jedi; sergathome; acanta; +3 Ответить
48. acanta 22.04.19 18:27 Сейчас в теме
(47) а что вы понимаете под клиентским контекстом и как представляете себе параллельность в нем? Особенно в режиме терминала и десятке веб браузеров..
Представим себе на минуту, что в обсуждаемом логическом выражении платформа будет вычислять каждый результат в отдельном потоке на разных ядрах процессора.
То, что они вычисляются в 8 ке последовательно и вычисление прерываются при бессмысленности продолжения это допущение платформы 8, оптимизирующее ее же ограничения.
Я бы не стала строить на этом костыле работу такого количества людей.
50. sergathome 4 23.04.19 08:51 Сейчас в теме
(48) Разумеется сервер имеется ввиду. "Десяток веб-браузеров" тоже можно покритиковать, но это отдельная тема. Смысл вот в чём - главная задержка это почти всегда запрос. Пока он исполняется много чего можно было бы сделать ;) Фоновое задание - это ядерная бомба, бомбить ей воробъёв чтота как-то некошерно. нет ?
Опять же коллега вам абсолютно правильно указал - потеря контекста - это очень большая потеря ;)
Hobbit_Jedi; acanta; +2 Ответить
80. bugagashenka 203 30.01.21 07:50 Сейчас в теме
(50)запрос это всегда сервер. ФЗ всегда сервер. И в типовых этот мифический запрос, взять любой отчет, выполняется в фоне. Логично? На 100500.
ФЗ это не ядерная бомба. Это, скорее, отвертка, отличный инструмент. Нормальные люди ей винтики крутят, дурак может и в глаз засунуть.
Потеря контекста в чем потеря? Кто мешает передать в параметрах все данные? Или даже форму(не помню, вроде можно ее на сервер утащить, проверять лень).
54. Darklight 33 23.04.19 09:59 Сейчас в теме
(48)Я об этом написал - параллельность - это не панацея. Но я за то, чтобы платформа сама решала (при содейситвии программиста) - что ей расспаралелить. Если у неё дефицит мощности - то распалить нет смысла - если избыток - то почему бы не рапараллелить - не понадобятся вычисления - да и фиг с ними - не убудет.

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

А, вот в серверном контексте, распараллеливание вычислений - дело очень важное.И Фоновые задания тут не панацея - очень тяжёлые они в использовании (затратные по ресурсам). Даже в современных ящыках программирования уже стараются отойти от иидеюю создания параллельных потков (шредов) в пользу других концепций управления ассинхроностью выполнения - вот и возникают асинхронные функции и корутины, где программист не отвечает за создание и управление потоками, а за это отвечает внутренние библиотеки языка - по необходимости, и сами потоки тоже кешируются в пул.

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

Так что - параллельность нужна и в серверном и в клиентском контекста - но нужно сделать её максимально удобной для программиста и максимально незаметной для пользователя (вернее как раз заметной - как отсутствие фризов). Вот, ассинхронные функции и фоновые потоки (в рамках текущего сеанса) - были бы очень кстати.
55. acanta 23.04.19 10:12 Сейчас в теме
(54) вы имеете ввиду нечто вроде "начатьвыполнениезапроса", процедураобработчикрезультатазапроса?
61. Darklight 33 23.04.19 12:50 Сейчас в теме
(55)Методологий создания асинхронного кода нынче напридумывано много. Но как вариант - да - как Вы написали - через объект "ОписаниеОповещения", но он, во-первых должен быть доступен в серверном контексте, а во вторых - я за то, чтобы можно было и свои асинхронные функции объявлять.

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

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

Ну и асинхронные циклы, хотя бы по коллекциям (и в т.ч. выборкам) - это тоже очень хорошо - но это отдельный паттерн.
79. bugagashenka 203 30.01.21 07:45 Сейчас в теме
(47) А можно чуть подробнее про процессы и потоки? Процессное распараллеливание, это когда в системе генерится столько экземпляров приложения, насколько предполагается параллелить. А потоковое, когда внутри, например, rphost создается несколько потоков. А теперь откройте 1С, сгенерируйте 4 ФЗ и посмотрите, сколько у Вас в системе появилось новых процессов. А потом откройте админку и посмотрите, сколько потоков.
По поводу клиентских параллельностей. Главный вопрос - зачем? Для чего генерить нагрузку на клиенте, если для этого есть сервер. Потому и архитектуру К-С придумали, чтобы можно было хоть с утюга работать. Кстати, умельцы даже на расберри запускают тонкие клиенты.
81. Darklight 33 01.02.21 10:57 Сейчас в теме
(79)Не смог понять, что вас смущает в процессах и потоках. Отличие системных процессов от системных потоков только в том, что системные процессы имеют изоляцию памяти, и часть общей памяти процесса разделяется между потоками (ну там ещё кое-что, по мелочи, для 32-битных приложений ещё процесс не может адресовать больше 2Гб памяти), а если они (процессы) управляемые - то они имеют и свой отдельный менеджер памяти. Из-за изоляции - межпроцессное взаимодействие более сложное и медленное, чем межпоточное. Зато, если упадёт поток процесса - он легко может потянуть за собой весь процесс. Поэтому в 64-бином сервере - разделение на процессы - это скорее вопрос надёжности. Хотя... нет... практика показывает, что в этом бывает и смысл производительности, но это либо тонкости низкоуровневого системного программирования по приоритезации использования времени ядра процессора на процесс, либо особенности оптимизации потоков одного процесса - чем их на процессе больше а обслуживаемые задачи разнороднее - тем больше накладных расходов - вот и делят потоки на разные процессы, каждым из которых управлять проще, а его задачи более однородны (есть ещё нюанс - межпроцессорное взаимодействие двух разных потоков более медленное, чем в рамках одного процессора - это уже особенности архитектуры процессоров и ОС; поэтому потки, обрабатывающие одни и те же данные - стараются размещать на одном и том же процессоре, на разных ядрах).

В управляемых приложениях (не путать с управляемыми приложениями 1С) в последнее время чаще стали набирать популярность ещё и виртуальные потоки - где кодом алгоритмов управляем само управляемое приложение - прерывая его выполнение в дозволенных местах и передавая поток выполнения другому коду. Вот отсюда в первую очередь и растёт асинхронность - которая может быть без параллельности даже - алгоритмы выполняются частями строго друг за другом (а при затребовании параллельности - управляемое приложение само распределяет такой код по потокам, постоянно переиспользуя уже запущенные потоки - что сильно экономит время и ресурсы на мелких параллельных операциях).
И такая асинхронность пришла в 1С с релизом 1С Предприятие 8.3.18
Но без параллельности - это не более чем синтаксический сахар.
Да и эта асинхронность доступна только на клиенте - хотя в других платформах - наоборот - чаще на сервере ей пользуются!

По поводу клиентской параллельности, мне кажется, я ранее дал достаточные разъяснения ЗАЧЕМ! В первую очередь, чтобы не фризить клиент! Интерфейс пользователя должен быть живым всегда, если это не создаёт серьёзных проблем текущим выполняемым процессам. Да, можно почаще порождать фоновые задания - (отчёты уже так и формируются, можно и документы так проводить). Но это не всегда эффективно.

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

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

В-четвёртых, это перерасходы лицензий - фоновые задания - это отдельные процессы, которые требуют отдельную клиентскую лицензию - пожалуй это главный довод 1С - почему нет отдельных потоков - это выгодно самой компании 1С - если штат из 100 пользователей будет реально потреблять не 100-125 лицензий как ранее (условно до управляемых приложений), а 200-300 в пике (и ограничения на один сеанс на базу тут почти ничего не решают) - это же какой профит 1С (добавить сюда и программные лицензии раздаваемые сервером на сеанс и в ряде случае это явно будет уже ближе к 400 лицензиям). Пока это не столь заметно - т.к. современные конфигурации не дружны с параллельностью. Но со временем, если перестроить их на активно-фоновые - то можно доходить и до 1000 лицензий на на 100 пользователей в пике). Это выгодно, но не современно! Пока это не приводит к существенному оттоку клиентов. Но что будет далее? В будущем другие платформы, лишённые таких перерасходов явно будут куда интереснее. Уж лучше выпустить две версии 1С Предприятие (да как и сейчас ПРО и КОРП) - одну без многопоточности (оставить два физических потока и виртуализацию управляемой асинхронности) но с более дешёвыми лицензиями, и одну с многопоточностью - но более дорогими лицензиями (ну как минимум раза в 2).

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

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

В-седьмых, аналогично и с вызовом с клиента WEB-Сервисов и HTTP-Соединений - если бы на других платформах для этого нужно было бы вызывать сначала сервер, там создавать фоновый процесс, чтобы просто обратиться асинхронно по WEB-адресу - то работа в Интернет была бы ну очень медленной!

В-восьмых, даже если мы что-то вызвали в фоне на сервере - нам ведь нужно получить результат - вот как это всё отслеживать в том же потоке, где и основная работа? Если на клиенте для этого использовать "ПодлкючитьОбработчикОжидания" - то он периодически будет фризить клиент - это очень раздражает! А если отслеживать нужно сразу несколько фоновых заданий? Да - 1С система взаимодействия тут может помочь - но она не входит в основную поставку, да и сам процесс обработки взаимодействия сервера с клиентом опять будет фризить клиент!

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

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

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

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

И в конце ещё раз акцентирую внимание. Задачи и ситуации применения клиентов бывают разные. Сейчас всё более им более все уходят в облака с в WEB-клиентами, где на клиентах остаётся минимум нагрузки. Нагрузки то минимум, но задач, которые нужно выполнять параллельно даже в окне браузера - меньше не сильно становится. Вот и JavaScrtipt изначально не разрабатывался для параллельности - но тем не менее, в WEB-разработке он часто используется для выполнения многопоточных задач (нашли обходные пути, пусть и кривые), а в серверном Node.js так и само ядро движка JavaScript было изменено - чтобы поддерживать и параллельность и распределённость!
А параллельность на клиенте нужно вводить аккуратно - как доп возможность, включая её на тех клиентских платформах, где это возможно и необходимо! Иначе - применять виртуальную параллельность - где платформа сама переключает выполнение потока команд. Как это сделать - посоветуйтесь, например, у JetBrains - у них хорошо получается!
Hobbit_Jedi; +1 Ответить
82. tormozit 7230 01.02.21 18:43 Сейчас в теме
(81)
фоновые задания - это отдельные процессы, которые требуют отдельную клиентскую лицензию
Ты ошибаешься - фоновые задания не используют клиентские лицензии https://partners.v8.1c.ru/forum/t/1229098/m/1229428
83. Darklight 33 02.02.21 12:33 Сейчас в теме
(82)Всегда был уверен, что расходуют. Увы, нет доступа у меня к партнёрскому форму - поэтому прочесть не могу. Но даже если так на 4-тый довод моего комментария это принципиально не влияет.
Если у компании 1С нет интереса в повышенном расходе лицензий за счёт условно-параллельного выполнения процессов (фоновых заданий) на сервере - тогда тем более нет логического смысла в дальнейшем лишении платформы многопоточного программирования (не в 8-ке, конечно же, а в как минимум в 9-ке, хотя и в 8-ке тоже можно было бы - хотя бы грубо - но сделать)
Остаются только такие доводы против:
1. Технически сложно - да 1С Предприятие 8 разработана на C++ (кроме web-клиента) - этот язык не особо дружелюбен к многопоточному программированию, тем более динамическому (не с фиксированной архитектурой оптимизированных потоков). Но, сложно - не значит невозможно - хотя бы в простейшем виде - сделать можно было бы (готовых библиотек на эту тему много, упрощающих многопоточное программирование на с++) . 9-ю версию 1С Предприятие уже точно стоит разрабатывать на каком-то более дружелюбном языке и управляемой платформе.

2. На WEB-Клиенте весь исполняемый на стороне клиента код - это JavaScript - а его движок изначально однопоточный - но web-программисты давно научились выкручиваться. Kotlin тоже умеет конвертировать свои корутины в JavaScipt - так что это сложности - но они преодолимые

3. Нужно разработать что-то простое (API) для программистов 1С - чтобы многопоточное программирование не превратило разработку в Ад. Ну... 1С за последние годы и так превратила разработку в 1С со своими БСП, накрутками платформы (нафиг ненужными 90% потребителям) и адовой архитектурой типовых конфигураций - уже не привыкать.
Ну а для упрощения многопоточки - сейчас в сторонних управляемых платформах много есть простых библиотек и подходов. Это и вариации на тему задач/промисов - и вариации по лёгкому распараллеливанию циклических операций - PLINQ. Да и к фоновым задачам (аналог тасков в многопоточке), как и к обработчикам оповещения (аналог колбэков в многопоточке) людей уже приучили. Сейчас приучат ещё и к асинхронным функциям (особенно если добавят её в серверный код). Ну а в будущем - в 9-ке стоит делать ставку больше на декларативное программирование и кодогенерацию - чтобы программисты больше думали над логикой задач, чем над особенностями их детальной реализации и оптимизации

4. Придётся усложнить процесс управления блокировками данных - многопоточка тут действительно добавит своих сложностей. Причём блокировки будут не только данных СУБД но и данных объектной модели. Это весьма серьёзные нововведения. Но при смене редакции платформы 1С были и куда более серьёзные новации, ломающие прошлые навыки и подходы к программированию и работе пользователей

5. Придётся отбиваться вот от таких вот претензий (79):
- Зачем многопоточное программирование на клиенте - коли все вычисления выносятся на сервер (выше как раз пояснил зачем)
- Зачем многопоточкой нагружать сервер - а нём и так работают пользователи - каждый активный сеанс - выполняет свой код в отлдельном потоке (+ системные и дополнительные платформенные) - и уже десяток другой сеансов - это легко создаст несколько десятков потоков. А сто активных сеансов на рабочий сервер кластера 1С (для крупных предприятий) даст и более 200-300 активных потоков на сервер.
Ну... это сейчас может показаться достаточным. Реально - даже 300 поток для серверов через 10-20 лет - это ничто! Уже сейчас есть 32ядерные серверные процессоры. А через 10 лет будут и 128 ядерные - это минимум 512 ядер на сервер (4 камня) способных легко перемолоть более 1000 активных потоков! И это будет стоят в рядовых серверах 1С. А реально - даже сейчас 8ядерные слабенькие сервера из 4-х камней - вполне себе перемалывают более 64 активных потоков - что хватает для текущих задач. Но, следующий апгрейд на 16ядерные камни - и будет запас мощности.

Тут возразят:
а) Сейчас активно применяют виртуализацию - лишние ядра просто распределят на другие задачи.
б) Довольно популярным решением у не крупных компаний является совмещение сервера 1С Предприятие 8 и сервера СУБД - лишние мощности отъест SQL Севрер (возможен и гибрилный вариант - где виртуализируется и сервер SQL - и там в разное время Сервер 1С Предприятие и SQL Сервер могут быть как на одном хосте так и на разных)

Отвечу - все эти схемы - лишь ответ на то, что Сервер 1С Предприятие 8 редко может эффективно утилизировать свои вычислительные ресурсы (причём, происходит это, обычно, за счёт просадки СУБД или неэффективных алгоритмов). А когда может - то это скорее уже просто глупость, лень (переделать) или безденьежье.
Если за счёт распараллеливания можно было бы куда эффективнее нагрузить Сервер 1С Предприятие - ускорив работу пользователей. И куда более качественно распределяя ресурсы между ними - ведь не все пользователи в одно и то же время нуждаются в одинаковых мощностях. Вот поэтому в управляемых приложениях на других платформах и перешли от модели жёстких потоков - к модели тасков/задач/корутин - когда сами параллельные алгоритмы более гибки в том как им использовать доступные параллельные мощности с минимальными оверхедами затрат ресурсов на эту параллельность!

Программистам 1С (и всей платформе) нужно дать больше гибкости в управлении потоками вычислений. При этом сам API этого управления не должен быть сложным в освоении и минимизировать негатив от не совсем правильного применения. Но на эту тему уже много чего придумали на других платформах - есть из чего выбрать!
Лично мне нравится подход языка C# - с его Task и PLINQ. Корутины в Котлин тоже неплохи. Да и Промисы Java хоть и немного устарели в своей реализации, но с идейной стороны - вполне себе мощный и перспективный вариант!
Интересные новации есть и в пользовательских библиотеках для Python...
46. Darklight 33 22.04.19 18:22 Сейчас в теме
(43)Даёшь корутины в 1С!

Вообще - для начала дали бы возможность писать свои собственные асинхронные методы - а то встроенные есть - хочется и свои, и чтобы можно было их и в серверном контексте использовать. Но... как мне кажется - это не техническое, а чисто идеологическое и коммерческое ограничение - так что не будет этого в 1С. По крайней мере, до 9-й платформы, а там уже можно будет кардинально лицензионную политику пересмотреть и цены на разные версии платформы по-разному привлекательно обосновать. Только 9-ку я бы вообще в обозримом будущем не ждал бы. в лучшем случае - к середине века...
51. sergathome 4 23.04.19 09:02 Сейчас в теме
(46) Техническое, думаю. Когда, в своё время, вышла первая FastReport с мултисредингом, то, помучавшись полгодика, вернули её назад в синхорон... Следующая попытка случилась только через пару лет ;)) А тут, имхо, основной момент, как я выше уже написал, - заполнить паузы при ожидании запросов. А это, как минимум, переделка обмена с SQL, а их - 3 модели + файловая и всё в этом тонет... :(
52. Darklight 33 23.04.19 09:39 Сейчас в теме
(51)Добавление параллельности в платформу - дело сложное. Но такова тенденция XXI века в IT технологиях - и сейчас постоянно появляются всё новые и новые идеи как эту параллельность сделать наиболее простой для программиста. Более того, я думаю будущее - за интеллектуальными компиляторами - которые буду сами решать как распараллелить написанный алгоритм (и вообще - нужно ли это делать; вообще интеллектуальные компиляторы будут много чего уметь делать за программиста, а не только оптимизировать алгоритмы).

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

Всё, иных проблем с доступом к базе не должно быть - ибо СУБД вполне нормально поддерживают параллельную работу (но внутри полатформенного внутреннего контекста кое-что наверняка переписать придётся, особенно если там много статических классов, которые обычно мало пригодны для параллельной работы).

Я всё-таки считаю что асинхронность в программировании нужна не столько для заполнения пауз между длительными операциями, сколько для оптимизации этих длительных операций, когда фоновые задания слишком тяжелы или невозможны - Клиентский контекст. Но, конечно, это, скорее исключение, в первую очередь - это серверный контекст - но, там, кто-то может заметить, что параллельность не нужна - т.к. там и так идёт многопользовательская работа - и процессоры и так постоянно параллельно нагружаются разными клиентскими сеансами-процессами и фоновыми заданиями. Но, всё-таки параллельность к формированию таки алгоритмов позволила бы платформе более эффективно и равномерно распределять нагрузку процессоров, особенно для не постоянно выполняемых но очень тяжёлых операций обработки данных - создающих пиковые нагрузки на один процесс-сеанс.
4. screenplayer 21.04.19 11:49 Сейчас в теме
Не вижу смысла.
Soloist; premierex; +2 Ответить
7. json 3349 21.04.19 13:27 Сейчас в теме
Так то все конечно выглядит красиво, но в данном примере функции СоздатьКатрочкуНоменклатуры() и СоздатьЕдиницыИзмерения() - должны возвращать ссылку на созданный элемент справочника. Эти две ссылки должны бы передаваться в метод ЗаписатьБазовуюЕдиницуИзмерения().
Иначе придется использовать глобальные переменные. А это не рекомендуется стандартом п 3.2

Я к тому, что идея выглядит красиво, но на практике ровно в таком виде - применить получится крайне редко.
Почти всегда придется искать компромиссы.
А вот тема таких компромиссов в публикации не раскрыта
Hobbit_Jedi; Ditron; CyberCerber; rpgshnik; zqzq; +5 Ответить
8. Vortigaunt 97 21.04.19 13:34 Сейчас в теме
(7) Вы забываете про параметры функций. В данном конкретном примере я бы рекомендовал что-то подобное:
Песочница = Новый Структура;
Возврат СоздатьКатрочкуНоменклатуры(Песочница)
	И СоздатьЕдиницыИзмерения(Песочница)
	И ЗаписатьБазовуюЕдиницуИзмерения(Песочница)
	И ЗагрузитьШтрихкоды(Песочница)
	И ЗагрузитьЦены(Песочница);


У меня в обработке вместо структуры была строка табличной части, но это не меняет сути. В структуру мы можем записывать любые данные, которые потребуются следущим функциям для работы. А в самих функциях можно проверять наличие значения через метод Свойство("Ключ", Значение).
9. acanta 21.04.19 13:42 Сейчас в теме
(8) Спасибо. Где то писали что в современных языках программирования все параметры функций легко превращаются в одну единственную структуру.
Это следующий уровень абстракции.
Hobbit_Jedi; wolfsoft; +2 Ответить
10. json 3349 21.04.19 14:30 Сейчас в теме
(8) ну это конечно снова компромисс, т.к. мы теперь не видим какие ключи должны быть в структуре, в каких методах эти ключи назначаются, а в каких методах используются.
Нужно будет провалиться в каждый метод, чтобы это понять. Если наши проверочные функции не совсем примитивные, то нужно будет потратить время, чтобы разобраться в таком спагети.
Также, мы не сможем просто так взять и отключить любую проверку, т.к. в ней могут рассчитываться переменные для следующих проверок
Еще мы не сможем переставить проверки местами без анализа их самих. А это совсем не очевидно.

Но в принципе, я не критикую. На самом деле у такого подхода есть плюсы и минусы. И каждый их оценивает в соответствии со своим опытом.
Rabot; Hobbit_Jedi; PLAstic; CyberCerber; zqzq; +5 Ответить
11. riposte 391 21.04.19 16:03 Сейчас в теме
Существует несколько аспектов хорошего кода.
Но самый главный из них - его читаемость.
Хороший код пишется один раз, а читается много раз.
И дело не в комментариях к каждой функции, а в самом коде. Читая его, у тебя не должно возникать вопросов "А это откуда, а это куда, а там что происходит, а это зачем?".
Подобные конструкции не улучшают понимание происходящего, а только уменьшают на N количество строк.
С тем же успехом можно писать
Если НЕ СоздатьКарточкуНоменклатуры() Тогда Возврат Ложь; КонецЕсли;

И желаемая "лаконичность" будет достигнута.

Ну а эти сложные конструкции из функций, связанных в И\ИЛИ\НЕ - ладно если у тебя там именно проверки, типа
(ПользовательИмеетПрава() И ПользовательМолодец()) ИЛИ ПользовательБездействовал()

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

Вот тебе еще пример
a = 'asdasd'
if b>0:
   a = None

a = 'asdasd' if b <= 0 else None

Первый вариант ты прочитаешь как абзац книги и даже не задумаешься.
Второй - ты будешь, пускай и несколько секунд, но осмысливать. Изречение Йоды мастера как.
Garik8866; user591389_aska_rabota; Hobbit_Jedi; Дмитрий74Чел; mivari; abadonna83; CyberCerber; SlavaKron; Soloist; rpgshnik; McSim; Merkalov; BigB; +13 Ответить
12. BigB 193 21.04.19 20:30 Сейчас в теме
(11) Мне вот так читается как абзац книги:
a=?(b<=0,None,'asdasd')
Hobbit_Jedi; wowik; CyberCerber; rpgshnik; jONES1979; +5 Ответить
13. riposte 391 21.04.19 22:02 Сейчас в теме
Согласен, не совсем удачный пример.
a = 'asdasd' if b <= 0 else None

Для меня тоже как абзац. Сейчас.
Я думал, будет очевидно, что речь не про a и b, а в том, что a=?(b<=0,None,'asdasd') предлагают писать как
a = SomeFunction() or SomeOtherFunction() and SomeFunctionVersion2() and not DoSomeStuff()


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

Не говоря уже о том, что если ты делаешь что-то посерьезнее печатных форм и линейных обработок, тебе нужно возвращаться к своему коду снова и снова, и читать его снова и снова. Дебаггинг таких конструкций будет просто невыносим. И каждый раз, натыкаясь на них, ты будешь еще и время тратить вспоминая или осознавая, что же тут так красиво зашифровано в этих перипетиях логической пляски.
user591389_aska_rabota; Hobbit_Jedi; PLAstic; +3 Ответить
14. CheBurator 2712 22.04.19 00:47 Сейчас в теме
я бы попросил не писать много этажных конструкций если а использовать явное указание на "прекращение" вычисдения

Вместо

цикл Услвоие
если чтото1 Тогда
если чтото2 Тогда
//тут много кода длинного и хз что там в конце как делается
пишите покороче.

цикл Услвоие
Если НЕ чтото1 Тогда Продолжить; КонецЕсли;
Если НЕ чтото2 Тогда Продолжить; КонецЕсли;
//тут линейный код который не зависит от условий
user591389_aska_rabota; Perfolenta; rpgshnik; +3 Ответить
15. Perfolenta 206 22.04.19 03:08 Сейчас в теме
(14) прикольно, я тоже этот совет многим начинающим даю... :)

еще такой, например:

Если чтото Тогда
//мало строчек кода
Иначе
//много строчек кода
КонецЕсли;
потому, что когда наоборот, то наглядность логики падает...

а в своём языке программирования, который я сейчас делаю, я придумал операторы
Цикл
ПрерватьЕсли что-то;
ПродолжитьЕсли что-то;
КонецЦикла;
мне кажется красивые операторы :)
30. bugagashenka 203 22.04.19 13:19 Сейчас в теме
(15) а чем не угодил цикл < Пока [Условие] Цикл >?
32. Perfolenta 206 22.04.19 14:01 Сейчас в теме
(30) обычный цикл Пока тоже есть... я в данном случае писал про операторы
ПрерватьЕсли что-то;
ПродолжитьЕсли что-то;

иногда приходится писать бесконечный цикл вида:
Пока Истина Цикл
для таких случаев я предусмотрел просто Цикл
20. Lapitskiy 1061 22.04.19 06:28 Сейчас в теме
Автор поднял обсуждение проблематики, молодец!
Но если спросить любого квалифицированного много лет программирующего ПРАКТИКА, а не Теоретика Кода, то лучше писать многоуровневые условия, как в (14). Это будет "научно неправильно", но 1000% удобно для поддержки.
Код должен быть а) понятен даже новичку б) легко модифицируем в) легко отлаживаем
А подход, предлагаемый в статье, описывает некоего "сферического коня в вакууме", просто как идею. Автор, поверь, через некоторое время ты вернешься к тому, от чего пытался уйти, но за попытку разобраться ставлю +
user591389_aska_rabota; Hobbit_Jedi; ManyakRus; CratosX; Алексей_mir2mb; zqzq; +6 Ответить
16. timeforlive 16 22.04.19 03:32 Сейчас в теме
Код пишется для человека, а не для машины.
К чему такой рефакторинг "лишь бы без скобок"?

Я лучше отдельными блоками напишу код, тогда мне хватит одной секунды понять как тут все работает.
user591389_aska_rabota; Hobbit_Jedi; +2 Ответить
17. Oldsad 22.04.19 03:47 Сейчас в теме
Песочница = Новый Структура;
Возврат СоздатьКатрочкуНоменклатуры(Песочница)
    И СоздатьЕдиницыИзмерения(Песочница)
    И ЗаписатьБазовуюЕдиницуИзмерения(Песочница)
    И ЗагрузитьШтрихкоды(Песочница)
    И ЗагрузитьЦены(Песочница);

Проблемы с подобным у вас начнутся, когда например возникнет ошибка в параметрах передаваемых в последнюю функцию
По самым скромным прикидкам потребуется в два три раза больше времени, чем на отладку обычного кода
Hobbit_Jedi; +1 Ответить
39. Perfolenta 206 22.04.19 17:11 Сейчас в теме
(17) не слишком-то и вырастут затраты времени на отладку...
- устанавливаем точку останова на Возврат
- нажимаем F10 - мы выполнили первую функцию, если мы стоим на второй, то с первой все в порядке, а если сразу вышли, значит функция вернула Ложь и в ней ошибка...
... повторяем для всех функций...
для последней функции анализируем возвращенное значение...

узнав функцию в которой ошибка, ставим точку останова в ней (или заходим по F11) и отлаживаем... времени надо совсем чуть-чуть больше, чем на обычный код...
18. Oldsad 22.04.19 03:57 Сейчас в теме
Вариант №1
Возврат СоздатьКатрочкуНоменклатуры()
	И СоздатьЕдиницыИзмерения()
	И ЗаписатьБазовуюЕдиницуИзмерения()
	И (НЕ ИспользуютяХарактеристики ИЛИ СоздатьХарактеристики())
	И (НЕ ВесовойТовар ИЛИ ЗагрузитьКодыВесовогоТовара())
	И ЗагрузитьШтрихкоды()
	И ЗагрузитьЦены();


Вариант №2
Результат = НЕ СоздатьКарточкуНоменклатуры()
	ИЛИ НЕ СоздатьЕдиницыИзмерения()
	ИЛИ НЕ ЗаписатьБазовуюЕдиницуИзмерения()
	ИЛИ ИспользуютсяХарактеристики
		И НЕ СоздатьХарактеристики()
	ИЛИ ВесовойТовар
		И НЕ ЗагрузитьКодыВесовогоТовара()
	ИЛИ НЕ ЗагрузитьШтрихкоды()
	ИЛИ НЕ ЗагрузитьЦены();

Возврат НЕ Результат;
Показать

первый вариант достаточно легко читается, во втором 9 человек из 10 сходу не сможет сказать что будет результатом на выходе функции
в среднем логическое отрицание (НЕ) значительно усложняет простоту восприятия логических выражений
user1455510; Hobbit_Jedi; CratosX; Hans; +4 Ответить
71. Hans 3 11.10.19 10:27 Сейчас в теме
(18)Тоже так подумал. НЕ надо избегать.
19. bugagashenka 203 22.04.19 05:15 Сейчас в теме
Возврат СоздатьКатрочкуНоменклатуры()
	И СоздатьЕдиницыИзмерения()
	И ЗаписатьБазовуюЕдиницуИзмерения()
	И (НЕ ИспользуютяХарактеристики ИЛИ СоздатьХарактеристики())
	И (НЕ ВесовойТовар ИЛИ ЗагрузитьКодыВесовогоТовара())
	И ЗагрузитьШтрихкоды()
	И ЗагрузитьЦены();


Я, конечно, дико извиняю, но имена функций, возвращающих булево, просто жесть.
Вот, пожалуй, оставлю это здесь.
https://its.1c.ru/db/v8std#content:2149184296:hdoc
Hans; Somebody1; timeforlive; Bazil; ArchLord42; SlavaKron; pavlov_dv; +7 Ответить
22. ArchLord42 83 22.04.19 07:52 Сейчас в теме
(19) А что жесть то?

Наименования соответствует пункту 6.5 приведенного вами же стандарта.
А про возврат булево в стандарте ни слова нет.

Да и как бы разрабы БСП иногда используют такой же прием, только в умеренных дозах, тут перебор офк, замучаешься дебажить такие цепочки.
26. bugagashenka 203 22.04.19 11:06 Сейчас в теме
(22) 6.5 подразумевает действие над объектом или формой, возвращая при этом успех операции, а в аргументе само значение. Как в примере - действия над формой и, в случае неудачи, ввернуть ложь.
В конкретно данном случае логичнее и читабельнее было бы использовать флаг отказа в аргументах функции.

В Вашем примере что должна сделать функция СоздатьКарточкуНоменклатуры()? Создать элемент справочника? А может в функции проверяется необходимость создания и в результате передать управляющий флаг на создание номенклатуры?

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

Функция ВыполнитьПроверку(Параметр1, Рекв, ТЗ)
Функция ПолучитьМассивыРеквизитов(ХозяйственнаяОперация, МассивВсехРеквизитов, МассивРеквизитовОперации)

Правильно:

Функция РеквизитОбъектаЗаданногоТипа(Объект, ИмяРеквизита, ТипЗначения)
Функция ЗаполнитьИменаРеквизитовПоХозяйственнойОперации(ХозяйственнаяОперация, ИменаВсеРеквизиты, ИменаРеквизитыОперации)
ArchLord42; +1 Ответить
31. ArchLord42 83 22.04.19 13:37 Сейчас в теме
(26) Кстати да, Вы чертовски правы!
72. CratosX 114 12.10.20 19:44 Сейчас в теме
(19) такой страницы по ссылке не существует
21. rpgshnik 3795 22.04.19 07:02 Сейчас в теме
Пришел к мнению различных веяний, что легко читаемый код будет для меня такой:

Если НЕ СоздатьКарточкуНоменклатуры() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ СоздатьЕдиницыИзмерения() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗаписатьБазовуюЕдиницу() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗагрузитьШтрихкоды() Тогда
   Возврат Ложь;
КонецЕсли;
Если НЕ ЗагрузитьЦены() Тогда
   Возврат Ложь;
КонецЕсли;

Возврат Истина;
Показать


Возврат ИСТИНА
И СоздатьКарточкуНоменклатуры() = ЛОЖЬ
И СоздатьЕдиницыИзмерения() = ЛОЖЬ
И ЗаписатьБазовуюЕдиницу() = ЛОЖЬ
И ЗагрузитьШтрихкоды() = ЛОЖЬ
И ЗагрузитьЦены() = ЛОЖЬ


Первый плюс кода выше, использовать методику https://infostart.ru/public/152801/, суть которую уловил: начинать выражения И со строки ИСТИНА и каждое новое сравнение с новой строки, а выражения ИЛИ со строки ЛОЖЬ. Это позволяет каждую строчку закомментировать если в ней отпала необходимость или написать комментарий напротив.
Второй плюс это замечание коллеги (https://infostart.ru/profile/242382/), который давно сказал, что читабельнее именно сравнение со значением а не просто «НЕ СоздатьКарточкуНоменклатуры()». Я с ним полностью согласен. Стал замечать, что мозг реально перестает меньше напрягаться при чтение таких выражений, когда явно написано ЛОЖЬ или ИСТИНА после знака равно.

А про красоту кода, ну она должна быть в меру. Иногда перегибают палку как Дмитрий Малюгин - https://www.youtube.com/watch?v=hypgG2thQIE&t=5s когда за два пробела удар по яйцам :))) Всего должно быть в меру.
ManyakRus; Natalka_rus; +2 Ответить
23. SlavaKron 22.04.19 08:43 Сейчас в теме
(21) Тоже заметил, что условные выражения читаются легче с " = Ложь", чем с "НЕ", как ни парадоксально.
rpgshnik; +1 Ответить
28. PLAstic 296 22.04.19 12:02 Сейчас в теме
(23) А как вы читаете "Если НЕ Корректировка.Пустая() Тогда"? Пишете "ЗначениеЗаполнено()", что не одно и то же?
Я прекрасно читаю конструкции с "НЕ" и меня коробит от конструкций "Если ЭтоОшибка() = Ложь Тогда".

ps: начинал с asm'а, возможно, поэтому так.
Hobbit_Jedi; pfilyk; +2 Ответить
33. TODD22 19 22.04.19 14:02 Сейчас в теме
(28)
и меня коробит от конструкций "Если ЭтоОшибка() = Ложь Тогда".

В платформе есть метод(возможно несколько) которые исходя из названия должны возвращать булево, но при этом метод может возвращать как булево, так и ссылку.
Как то попался на этом....
(28)
ps: начинал с asm'а, возможно, поэтому так.

То же начинал с Асма вот не увидел связи....
34. SlavaKron 22.04.19 14:28 Сейчас в теме
(28) Посыл вашего комментария понял, но не сами предложения.
Я, как и вы, привык не использовать "= Истина/Ложь", — лишь стал замечать, что для быстрого понимания оно лучше. Работаю не один, стараюсь писать без лишней вычурности. На сложных выражениях внутреннего языка или запросов иногда использую Истина/Ложь.
73. CratosX 114 12.10.20 19:49 Сейчас в теме
(28) разница в том, что если функция ( ЭтоОшибка() ) или переменная будет содержать не булево значение, то это потенциально может привести к ошибке.
Например:

МояПеременная = Ложь;
//...куча кода, заход в другие модули
Если МояПеременная Тогда // упс, если МояПеременная например строка или ссылка.
74. PLAstic 296 12.10.20 23:37 Сейчас в теме
(73) Никакого упса. Будет неверно отрабатывать условие, но эксепшена не будет. Навык прямых рук прокачивается с опытом. Например, гуглим по УТ переменную Отказ и наблюдаем её жизненный цикл в рамках хотя бы одного документа. И ничего, никто с типизацией не ошибся в целой конфигурации. Соблюдайте стандарты и тогда у вас исчезнут универсальные переменные, которые используются и под дату, и под сроку, и под булево.
Hobbit_Jedi; +1 Ответить
75. FatPanzer 12.10.20 23:51 Сейчас в теме
(74)
Будет неверно отрабатывать условие, но эксепшена не будет.
Будет ошибка преобразования к типу Булево... То есть эксепшн.
76. PLAstic 296 13.10.20 18:21 Сейчас в теме
(75) Можно найти комбинации, когда будет ошибка. Но это уже напоминает анекдот "а вы на шкаф залезьте".
Мой чуть более чем 20тилетний опыт на 1С показывает: если переменные именовать согласно стандартам, ошибок не будет.
77. FatPanzer 13.10.20 18:27 Сейчас в теме
(76) Полностью согласен. Кроме одного:
Будет неверно отрабатывать условие, но эксепшена не будет.
Вот тут вы не правы.
24. Dmitrij-2 48 22.04.19 09:00 Сейчас в теме
"Оператор И спотыкается на лжи, а оператор ИЛИ спотыкается на правде”. - Только за это плюс
27. user1208474 22.04.19 11:42 Сейчас в теме
Вакансия программиста 1С Киев 50 тыс грн
58. pfilyk 23.04.19 12:28 Сейчас в теме
(27) какие требования? огласите весь список
29. palsergeich 22.04.19 12:05 Сейчас в теме
Логические выражения более 3 х операндов - в функцию.
Это будет красивый и поддерживаемый код.
Те простыни что в статье, в том числе и результат - не красивый код.
Результат = НЕ СделатьЧтоТО();

Возврат НЕ Результат;

Функция СделатьЧтоТО()
Здесь линейные булевы вычисления
КонецФункции
35. Darklight 33 22.04.19 15:16 Сейчас в теме
Мне больше вариант с "ЕСЛИ ТОГДА ВОЗВРАТ" нравится - может он и более громоздкий, но его набор легко упрощается шаблонами, а логические выражения (с корнями из функционального программирования) хорошо смотрятся только если они простые - как в данных примерах, но если логика более ветвистая - то нагромождение череды блоков ИЛИ/И может здорово всё запутать и усложнить дальнейшее редактирование этой логики.
Поэтому если в логике есть вперемешку И/ИЛИ и таких условий более 4-5, или условия состоят не только хз вызова проверочных функций, но и содержат сами проверочные выражения, то я однозначно за "ЕСЛИ ТОГДА ВОЗВРАТ". Да и отлаживать их удобнее.

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

Использование проверок через блоки "ЕСЛИ ТОГДА ВОЗВРАТ" в начале функции тяготеет к парадигме контрактного программирования. Когда все проверочные условия выделяются определёнными (обычно, но не всегда) синтаксическими конструкциями - и каждый контракт обрабатывается отдельно (обычно ещё до вызова функции с контрактами) - вот были бы контракты в 1С - было бы куда красивее.

Или наоборот - был бы в 1С продвинутый паттерн-мэтчинг с условиями - тоже можно было бы красиво писать проверки.


И вообще - лично я за более декларативное написание кода алгоритмов - применение "ЕСЛИ ТОГДА ВОЗВРАТ" как раз более декларативное.

Ну а параллельность.... выполнения инструкций в 1С - это вообще сказки и мечты о несбыточном! Другое дело - что при проверки условий как раз параллельность может быть боком - т.к. часто последующие условия могут операться на уже пройденную проверку предыдущих условий, или быть более затратными по времени выполнения, чем предыдущие, которые чаще отфильтровывают дальнейшее выполнение (и, соответственно, затратную проверку).
Тут много нюансов....
37. PLAstic 296 22.04.19 15:34 Сейчас в теме
Вдруг обнаружил ещё такой нюанс. Выделять в отдельную процедуру или функцию код стоит тогда, когда он используется более одного раза. В примере из статьи обсуждается целостный процесс, который делится на последовательно выполняемые этапы, но нет задачи, чтобы этапы могли вызываться произвольно. Поэтому я бы оставил это в одной процедуре, разбив комментариями её части.
Hobbit_Jedi; +1 Ответить
38. Vortigaunt 97 22.04.19 16:40 Сейчас в теме
(37) Я тоже раньше так думал. Если код не будет выполняться более 1 раза, то оформлять его как отдельную процедуру\ функцию не надо. Но потом в одной записи курса по java-core услышал мнение, что вместо комментария к блоку операторов лучше этот блок вынести в отдельную процедуру, а саму процедуру обозвать говорящим именем. Тогда и код читается легче, и комментарии не нужны. И нет громоздких процедур на много строк.
Попробовал для себя и понял, что это удобно. Запись кода получается короче. Расстояния между блоками Тогда и Иначе влезают в 1 экран и сразу видно, что будет если Тогда и когда Иначе. Плюсом на будущее такой код легче редактируется и развивается. Из готовых мелких операций потом легче собирать новые алгоритмы обработки.
user591389_aska_rabota; Darklight; +2 Ответить
40. Perfolenta 206 22.04.19 17:28 Сейчас в теме
(38) у такого подхода тоже есть минусы... я, например, очень не люблю перемещаться туда-обратно между кучей мелких процедур, когда ищу где-же делается то, что мне надо найти...
гораздо приятней просто крутить длинную процедуру до конца...
"говорящее" имя может оказаться только для вас говорящим... а для читающего ваш код впервые оно может только приблизительно намекать на то, что там внутри...
А ещё, когда в модуле только большие процедуры, то открывая список процедур быстро понимаешь, как устроен модуль... а если там десятки процедур с самыми разнообразными названиями, то уже трудно понять с чего начать, какие процедуры и функции важные, а какие просто обслуга... да и с точки зрения производительности вызов процедур не бесплатный, особенно в циклах и в рекурсии...
так что надо творчески подходить, где-то разбивать код на мелкие процедуры, а где-то и нет...
user591389_aska_rabota; Hobbit_Jedi; PLAstic; +3 Ответить
44. Darklight 33 22.04.19 18:16 Сейчас в теме
(40)
я, например, очень не люблю перемещаться туда-обратно между кучей мелких процедур

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

гораздо приятней просто крутить длинную процедуру до конца...

Обычно в таких больших процедурах очень быстро можно потерять суть в них происходящего и запуаться вблоках ветвления и циклов

"говорящее" имя может оказаться только для вас говорящим...

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

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

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

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

Это претензии к платформе - что она не умеет оптимизировать вызовы мелких процедур в циклах (автоинлайн) и рекурсию (разворачивание в циклы)

Замечу обратное, важное для 1С - что если бы типовая конфигурация была более мелко разбита на процедуры - то её обновлять было бы гораздо проще.
Но это справедливо и для рефакторинга своего/чужого программного кода.
А будь в 1С ООП - так разбиение на процедуры ещё и повысило бы эффективность применения полиморфизма.
56. Perfolenta 206 23.04.19 11:13 Сейчас в теме
(44) конфигуратор, конечно, не супер IDE... но я и не писал конкретно про конфигуратор...
я работаю на разных языках и проблемы везде одни и те же, программисты не идеальны, вне зависимости от того, выносят они код в отдельные процедуры или нет...

когда-то, когда еще не были осмеяны и затоптаны операторы GOTO и GOSUB, мы называли код некоторых товарищей взрывом на макаронной фабрике, именно из-за необходимости бегать по этим переходам туда-сюда-обратно, что бы понять написанное... в варианте разбиения на мелкие процедуры многие добиваются такого же взрыва на макаронной фабрике... эти люди просто переоценивают свои способности к декомпозиции и способности давать осмысленные имена... давать осмысленные имена это вообще достойно отдельной дисциплины...
Hobbit_Jedi; pfilyk; +2 Ответить
60. Darklight 33 23.04.19 12:42 Сейчас в теме
(56)Ну про снижение дисциплины среди программистов ещё Боб Мартин (автор книги "Чистый код") говорил. Но это уже другой вопрос. В остальном - современная IDE вполне должна оказывать достойную помощь в вопросах быстрого написания, анализа и рефракторный кода. Увы, конфигуратор 1С к таким IDE не относится :-(
49. Vortigaunt 97 22.04.19 20:20 Сейчас в теме
(40) Если бы любой код выполнялся линейно, то конечно приятнее просто листать сверху внизу и читать как книгу. Так можно залипнуть, и рабочий день кончился) Но почти всегда при анализе кода приходится скакать как сумасшедший в разные места и в разные модули. Сначала ищешь точку входа: ПриОткрытии(), ПередОткрытием(), обработчик кнопки Выполнить(), а потом ходишь по вложенным вызовам через F12, не забывая при этом ставить закладки в коде (F2), чтобы вернуться в то место откуда перепрыгнул.
Уже давно воспринимаю программный код не как свиток текста, а как древовидную структуру. И если код хороший, то от этого дерева можно "отрезать ветку" и использовать в другом месте практически без допиливания. Захотел, перенес часть функционала в модуль объекта и можно обработку подключить как фоновое задание. Захотел, вынес кусок в общий модуль - и твой код используется другими объектами. С большими процедурами, которые выполняют кучу операций, которые надо сделать здесь и сейчас именно так, все что написано выше практически невозможно. Это как будто на то дерево надели чехол и ты его можешь использовать либо целиком, либо никак.
user591389_aska_rabota; +1 Ответить
57. Perfolenta 206 23.04.19 11:44 Сейчас в теме
(49)
не забывая при этом ставить закладки в коде (F2), чтобы вернуться в то место откуда перепрыгнул.

закладки уже можно не ставить... с некоторых пор в конфигуратор добавили сочетания Ctrl+- и Ctrl+Shift+- позволяющие перемещаться назад и вперед...

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

"отрезать ветку" это конечно хорошо, но на самом деле это большая редкость, т.к. эти ветки чаще всего специализируются на задачах, которые больше ни где и никогда не понадобятся...
в синтакс-помощнике 1С описано не так уж много объектов, однако найти программистов помнящих все свойства и методы этих объектов найдется совсем не много, если вообще найдется... разбивая большую процедуру на множество мелких вы дополнительно увеличиваете поле методов, в котором придется ориентироваться программисту... главное не перестараться с этим...
я всего-лишь призываю к разумной достаточности... если вы сами в своей длинной процедуре чувствуете себя уверенно, то скорее всего и другие будут чувствовать то же самое... а если через неделю вы в ней потерялись, перепишите ее...
Vortigaunt; +1 Ответить
63. Vortigaunt 97 23.04.19 13:28 Сейчас в теме
(57) Я пытался донести несколько другую мысль. Как-то я заметил, что во многих задачах используется код, который я когда-то писал. Писал в разное время, используя разные стили, под разные задачи клиентов. И часто приходится рыться в завалах из внешних обработок и искать где та или иная задача реализована максимально удобно и без ошибок, затем копипастить, а затем... дописывать и править. Нельзя было просто вытащить кусок из старой обработки и вставить в новую. Он отчаянно цеплялся за элементы на форме этой обработки, за другие ненужные мне процедуры и функции. И решил, что хватит это терпеть. Потратил день и собрал st-шник из часто используемого кода. Так вот чтобы код не цеплялся за переменные или поля на форме обработки пришлось дробить и добавлять новые функции. Если раньше код для подключения к ФТП содержал в себе ссылки на поля: Адрес, Порт, Логин, Пароль, Папка. То теперь в этом коде добавились функции пустышки ФТП_Адрес(), ФТП_Порт() и т.д. И теперь в этих функциях можно реализовать чтение параметров откуда угодно: хочешь из полей на форме, хочешь из конфигурационного файла, хочешь из сохраненых настроек. Вместо простого Сообщить() в процедурах появилась ВывестиВЛог() и к ней процедура-пустышка ВывестиВЛог(), которая по умолчанию просто вывдит сообщение, но при желании можно вставить из st-шника блок процедур по сохранению логов и заменить функцию-пустышку. Как-то так. Решайте: перебор ли это, или наборот попытка упорядочить наработки.
user591389_aska_rabota; +1 Ответить
65. acanta 23.04.19 13:38 Сейчас в теме
(63) 8ка с ее контрол пробелом как бэ должна была избавить мир от шаблонов, но походу они стали сложнее.
На разработку своих шаблонов надо тратить драгоценное время. И постоянно их модифицировать.
sergathome; +1 Ответить
66. sergathome 4 23.04.19 13:49 Сейчас в теме
(65) Классическое противоречие тут получается - стоимость поддержки не окупает стоимость новой разработки. Платформа такова.
69. Perfolenta 206 23.04.19 16:32 Сейчас в теме
(63) то, что вы сейчас описали, старо как мир.. время от времени каждый программист пытается организовать себе свою библиотеку шаблонов... это разумно...
собственно и наследование в ООП, и библиотеки DLL, и разные компонентные технологии, преследуют в первую очередь ту же цель, повторное использование кода... однако, библиотеки сниппетов часто решают эту проблему не хуже, сегодня проблема памяти не стоит так остро, как в 90-е... поэтому копипаст тоже вполне допустим, особенно, если у вас есть возможность быстро находить нужный фрагмент кода...
но выше мы говорили о другом, о том, что разбивать большие процедуры на мелкие не может быть ни самоцелью, ни стандартом...
кстати, в старых книгах, написанных до появления ООП, можно почерпнуть много полезного о структурировании кода... ведь тогда как раз и было модным течением структурное программирование... сегодня структурное программирование это как раз уровень процедуры...
68. Vortigaunt 97 23.04.19 14:52 Сейчас в теме
(57) Кстати, спасибо за Ctrl + - и Ctrl + Shift + -. Реально удобно.
user591389_aska_rabota; +1 Ответить
59. pfilyk 23.04.19 12:32 Сейчас в теме
(38)все должно быть в меру, такой подход используется в документообороте, и очень напрягает бегать отладчиком по 10 модулям с вызовом 100500 функций туда сюда
Perfolenta; +1 Ответить
53. rabid_otter 134 23.04.19 09:50 Сейчас в теме
Офигеть, целая статья про Если Иначе КонецЕсли и куча вскукареков за параллелизм в 1С. Ну такое себе. От себя добавлю, что все написанное в статье уже было у Стива Макконнелла в книжке про совершенный код. Не придумывайте велосипеды.
62. VmvLer 23.04.19 13:26 Сейчас в теме
красивой может быть баба, а пытаться делать красивым код - это все равно, что мужику красить губы.

ничего личного, просто мысль.
64. acanta 23.04.19 13:31 Сейчас в теме
Если в главбухи снова пойдут мужчины (как до и после революции), уверена, женщины программисты будут заботиться о красоте кода даже спустя десятилетия промышленной эксплуатации.
Ничего личного.
user591389_aska_rabota; +1 Ответить
67. acanta 23.04.19 13:52 Сейчас в теме
(66)Есть спрос - есть предложение. Если в поддержку не закладывают стоимость нового значит считают что ничего не надо.
70. kosmo0 111 25.04.19 09:26 Сейчас в теме
не люблю конструкции вида

Возврат СоздатьКарточкуНоменклатуры()
И СоздатьЕдиницыИзмерения()
И ЗаписатьБазовуюЕдиницуИзмерения()
И ЗагрузитьШтрикоды()
И ЗагрузитьЦены();

Когда я отлаживаю сложные случаи, то не могу на лету изменить возвращаемое значение.
При коде

Результат = ....;
Возврат Результат;

Я могу присвоить любое значение переменной Результат. В последних платформах это типовой механизм, в более ранних с использованием Инструментов разработчика.

Так что. По возможности думайте немного шире нежели исключительно крастоа кода.
user591389_aska_rabota; ManyakRus; +2 Ответить
78. ManyakRus 489 20.11.20 09:35 Сейчас в теме
1. В каждой строке кода должна быть одна смысловая операция,
и наоборот: одна смысловая операция должна умещаться в одну строку кода.
2. Оператор "НЕ" использовать можно только в крайнем случае.
3. В операциях сравнения надо писать ".... = ИСТИНА", даже если оно необязательно.

В общем предложения автора ужасные.
85. user1424360 14.10.21 07:34 Сейчас в теме
Сейчас столкнулся с ошибкой, связанной с тем, что в выражении с оператором "И" первое выражение ЛОЖЬ, а второе все равно вычисляется и выдает ошибку. Платформа 8.3.17.1989, режим совместимости 8.3.14. В режиме совместимости 8.3.6 такой ошибки не было, все работало, как в статье.
86. tormozit 7230 14.10.21 10:47 Сейчас в теме
(85) Может ты путаешь "компилируется" и "исполняется"? Где доказательство?
87. user1424360 14.10.21 11:08 Сейчас в теме
Да, путаю. Только не компиляцию с выполнением, а другую вещь. Вопрос снимается.
88. AnryMc 848 03.12.21 09:26 Сейчас в теме

Вам ехать или шашечки?
Оставьте свое сообщение