Про простой и понятный код
Разработка - Рефакторинг и качество кода
Пятница, вечер. Сегодня провёл полдня в путешествии отладчиком по коду одной из типовых конфигураций, чтобы найти тот самый крошечный кусочек, который заставляет программу работать "именно вот так", в то время, как хотелось бы чтобы она в этом случае сработала по-другому. Крошечный кусочек кода, малюсенькая правка в нём - и ура, теперь работает как мне нужно! Но потратить полдня на эту задачу?..
Кстати, а как мы вообще тут оказались? Не в смысле как мы оказались на этой планете, а в таких вот обстоятельствах?
Давайте возьмём, например, такую, казалось бы, тривиальную операцию, как инкремент значения переменной.
Когда-то давным-давно мастера "старой школы" писали код вроде этого:
А = А + 1;
Сейчас, конечно же, кроме "фу, цэ мерзость!" ничего про такой код и сказать нельзя. Но программисты в те далёкие времена не были ещё избалованы многочисленными фреймворками и БСП, поэтому писали как Кнут на душу положит.
Шло время, виски программистов старой школы седели, страницы книжки Макконнелла "Совершенный код" безвозвратно желтели, а прогресс не стоял на месте.
И вот в наши замечательные времена, чтобы выполнить инкремент, уже имеет смысл написать хотя бы что-то вроде этого:
А = ОбщегоНазначения.Инкремент(А);
В общем модуле ОбщегоНазначения разместить функцию:
Функция Инкремент(ИнкрементируемоеЗначение) Экспорт
Возврат МатематическиеФункцииКлиентСервер.ВыполнитьАрифметическуюОперацию(
ИнкрементируемоеЗначение,
1,
МатематическиеФункцииКлиентСервер.ИдентификаторОперацииСложение()
);
КонецФункции
И, соответственно, в общем модуле МатематическиеФункцииКлиентСервер следующие функции:
Функция ВыполнитьАрифметическуюОперацию(Операнд1, Операнд2, ИдентификаторОперации) Экспорт
Результат = Неопределено;
Если ИдентификаторОперации = ИдентификаторОперацииСложение() Тогда
Результат = Операнд1 + Операнд2;
ИначеЕсли ИдентификаторОперации = ИдентификаторОперацииВычитание() Тогда
Результат = Операнд1 - Операнд2;
ИначеЕсли ИдентификаторОперации = ИдентификаторОперацииУмножение() Тогда
Результат = Операнд1 * Операнд2;
ИначеЕсли ИдентификаторОперации = ИдентификаторОперацииДеление() Тогда
Результат = Операнд1 / Операнд2;
Иначе
ВызватьИсключение "Неподдерживаемая операция " + ИдентификаторОперации;
КонецЕсли;
Возврат Результат;
КонецФункции
Функция ИдентификаторОперацииСложение() Экспорт
Возврат "Сумма";
КонецФункции
Функция ИдентификаторОперацииВычитание() Экспорт
Возврат "Вычитание";
КонецФункции
Функция ИдентификаторОперацииУмножение() Экспорт
Возврат "Умножение";
КонецФункции
Функция ИдентификаторОперацииДеление() Экспорт
Возврат "Деление";
КонецФункции
Внимательный читатель может меня упрекнуть, что во-первых, по сравнению с передовыми методиками разработки, в данном примере слишком малое количество вложенных вызов процедур и функций (например, совершенно не используется потенциал общих модулей с суффиксами "Служебный", "ПовтИсп", "Переопределяемый" и т.п.), во-вторых, что параметры в вызываемые функции передаются как позиционные аргументы, хотя логично было бы упаковать их в структуру, преобразовать в строку таблицы значений, поместить во временное хранилище и потом хотя бы пару раз сериализовать-десериализовать из/в xml или json. Ну и наконец, самый очевидный минус - это то, что вызов идёт не через ДлительныеОперации.ВыполнитьВФоне(...)! Ведь пока "хрустит" весь этот код, пользователь должен иметь возможность насладиться анимацией с котиками! Абсолютно с этим согласен. Просто хочу заметить, что это не готовая разработка, а всего лишь иллюстрация идеи, так сказать концепт, сильно упрощённый учебный пример для демонстрации современных тенденций в 1С-программировании. И при этом, хочу заметить, что несмотря на все описанные недостатки, пример всё же вполне рабочий и инкрементирует исправно!
Что нас ждёт в будущем? Скажу честно, я не футуролог. Но судя по общим тенденциям, открывая Конфигуратор (да-да, его родимый, а не эту вечную бету буржуйской EDT) мы скоро увидим что-то вроде:
P.S. На всякий случай, если вдруг найдутся такие, кто не поймёт: это был САРКАЗМ!
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 324 1 nedomolkov.ivan 1
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 350 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 467 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 503 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 442 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 501 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3431 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 314 Ninel_S 0
P.S. На всякий случай, если вдруг найдутся такие, кто не поймёт: это был САРКАЗМ!
сейчас разработчики стараются вместить в одну конфу все технологии, чтобы можно было одну конфу использовать в любом режиме... отсюда и усложнение ...
после крайнего обновления вообще ошалел от количества "закладок" при этом тайминг выполнения кода увеличилась, а утилизация ресурса сервера просто лишает слов и приличных выражений...
потратили 2 недели и это еще не все чтоб оптимизировать исполняемый код
для тестирования своего расширения я 50 раз запустил открытие КА 2.4 повторюсь - для тестирования печатной формы в расширении... и каждый раз у них выполняется ненужный кусок кода по 5 минут
А так да - всё по сути: чтобы передать соседу по столу соль - надо обязательно выехать из города и уже оттуда вернуться по точному указателю - где, кому, что и когда передать.
ГармоничнаяПеременнаяСохраненияСостоянияПроцессаПользователя
Да и типизация не помешала бы. Хотя бы опционально (хочешь - указывай, хочешь - нет)
ЗеленыйЧайСМолоком = ЗеленыйЧайБезМолока + 1
Если используется конструкция ЗеленыйЧайСМолоком += 1, то такая ошибка исключена.
Только вот с инкрементом это никак не связано.
Если боитесь запутаться в именах переменных: напишите функцию в глобальном модуле Инкремент(аЗначение, аДельта=1)
Лёгкий бред, конечно. Но переубедить называть переменные так, чтобы не путаться не получится((
Да бросьте, с чего вдруг ошибка будет исключена? Вы больше эту переменную не используете в коде?
Если не используете, зачем тогда инкремент?
А если используете, то на одно использование меньше, это вообще ни о чем.
Используйте Ctrl+пробел, если у вас есть опасения в потенциальной возможности такой ошибки.
ВЫБОР КОГДА Расчеты.Долг < 0
ТОГДА -Расчеты.Долг
ИНАЧЕ Расчеты.Долг
КОНЕЦНапример у меня давно есть такие глобальные функции как ЗЗ(Значение,ИгнорироватьПримитивные=Ложь,РежимПустого=0), НЗ(Значение), ЗН(Значение, ЗначениеПоУмолчанию=неопределено,ИгнорироватьПримитивные=Ложь,РежимПустого=0), Лог(Текст, Статус=неопределено, Приоритет=неопределено, Режим=неопределено, Данные=неопределено, Метаданные=неопределено), ОТ(ТипИлиИмяТипа,Длина=неопределено,ТочностьИлиРежим=неопределено,Знак=неопределено) - да читающему может быть поначалу не понятно, но таких функций не много, и они очень сильно ускоряют ввод кода - а с быстрым привыканием и его анализ.
Есть ещё подобны не глобальные, но давно думаю сделать их таковыми
Массив1(ЕдЗначение=неопределено), Свойство(Коллекция, ИмяСвойства, ЗначениеПоУмолчанию=неопределено, РежимПоУмолчанию=0, ДобавлятьВСлучаеОтсутсвия=Ложь), Скопировать(Коллекция, Рекурсивно=Истина), Кешировать(Ключ, ВычислениеЗначенияСтрока), ДополнительныйПараметр(Имя, ЗначениеПоУмолчанию=неопределено, Дата=неопределено, Организация=неопределено, Пользователь=неопределено, Узел=неопределено)
И некоторые другие....
Потому что, очень часто они используются!
Будь язык посовременнее - я бы из забацал как хэлперы/расширители для соответствующих типов, или даже инъекцировал бы в базовые прототипы этих типов!
Ну а хотя бы опциональная типизация да - не помешала бы - но это уже стопудово совсем другой язык выходит - 1С Исполнитель
глУвеличить(ГармоничнаяПеременнаяСохраненияСостоянияПроцессаПользователя);По-моему 6.0 была первой вехой в серии - и вообще первой платформой, получившей название 1С Предприятие. Но допустим... раз сохранили нумерацию с предшествующими платформами с именами 1С Бухгалтерия - то были ли кардинальные изменения в системе "программирования" 1С Бухгалтерии 1.0 - 5.0 у кого-то сохранившиеся в памяти - навряд ли - потому что программирования так как такового то и не было вовсе! Первые зачатки только стали появляться с 1С Предприятие 6.0
1. Произвести дополнительные операции при получении результата - от логирования и контроля доступа, до каких-то более хитрых операций ветвления. Кстати иногда может быть полезно и для отладки и отслеживания/поиска мест вызова.
2. Произвести подменю объекта - или даже просто произвести конструирование нового объекта, или произвести настройку типового.
То есть в первом случае это что-то типа эмуляции полиморфизма.
Во втором случае - эта фича перерастает в паттерн фабрик-классов.
Но да - без своих классов это дело трудное. Хотя - вот можно обработками, например, эмулировать.
Понятно - что такое вмешательство нужно не всегда и не всем - но когда это понадобится - то всё уже будет готово и не нужно будет перелопачивать весь кода - отсюда вытекает и:
3. Преемственность и прочность структуры кода - если в будущем возвращаемое значение изменится - не нужно будет (лукавлю конечно) переделывать все места применения, но получение нового значения - ведь функцию то они будут вызывать общую. При необходимости тут ветвление-версионирование организовать можно будет.
Причём (если совместимость конфигурации позволяет) - то эти функции можно менять не только напрямую, но в расширениях.
Но это всё в теории (и практике на других платформах программирования) - в 1С всё это далеко не так красиво работает. Но целом в таком подходе ничего плохого нет. Вот был бы ещё полноценный ООП.....
Ссылка вместо литерала полезна, например, при производстве кода:
- позволяет однозначно найти всех потребителей константы (например, командой "Найти использование", вместо глобального поиска по тексту) и, соответственно, найти потребителей текущей подсистемы (библиотеки)
- позволяет обозначить жесткую связь некоторого контекста с подсистемой (полезно как для программиста, так и для анализатора кода)
- упрощает отладку
...и много чего еще
Этот прием не противоречит правилам текущей вычислительной абстракции (1с платформа), не противоречит промышленной практике использования данной вычислительной машины. На "акробатические номера" это не тянет, в отличии от решений, которые иногда встречаются на этом ресурсе))) Не говоря уже о том, что эта часть относится к стабильному участку программного кода, который практически не зависит от места его эксплуатации. Итого, проще этот участок кода запомнить в голове, чем обсуждать его и разводить демагогии.
Это уже будет другой продукт, со своей историей (удачной или нет). Будет ли он с такой же рентабельностью для конечного потребителя приносить ему пользу - вопрос очень спорный.
Всё что Вы написали укладывается в мои постулаты. Да может я их не просто изложил - уж простите - особо не старался, вернее пытался как можно более абстрагироваться от прикладного уровня - к обобщённому.
С Этим не спорю - ООП - никогда не будет в типовой 1С Предприятие 8. Я просто сказал - что ООП XXI века вместе с данным подходом открыл бы поистине колоссальные возможности!
ОПП всегда был спорной парадигмой. Но сейчас ООП + функциональное программирование - это основа современного программирования. Фактически наступило перемирие между двумя самыми рьяными противниками - теперь у них симбиоз! Да и тот, не особо "красивый" ООП от Smaltalk до C++ уже почти канул в лету - сейчас в ООП наступила гармониям высокоуровневое упорядочивание.
Да и не стоит говорить, что ООП вообще нет в 1С - он есть ещё с 1С 7.0 - поросто его почти нельзя кастомно расширять - а от этого теряется бОльшая часть всех преимуществ его наличия. Сейчас в других платформах программирования ООП в тренде (как и функциональные аспекты) - было бы опрометчиво не включить его полноценную современную поддержку в новые продукты 1С с ЯП - так эти продукты были бы более понятны и более привлекательны новой волне современных программистов, которые уже со школы изучают ООП, и очень расстраиваются - когда нет его поддержки - к хорошему привыкаешь быстро!
А ещё на ООП базируется АОП (хотя частично можно и без него - и это делается уже в 1С хотя бы на примере Расширений конфигурации) - полноценного аспектного программирования очень нехватает в 1С Предприятие - это сильно упростило интеграционные моменты, модификацию и сопровождение модифицированного "типового" программного кода и метаданных.
Но ООП, конечно, не панацея - нужно и сами типовые конфигурации и библиотеки грамотно выстраивать с его применением. И на курсах прививать преимущества его использования - нужно перестраивать менталитет существующего 1С сообщества - а вот это куда сложнее. Когда человек привыкает ходить на карачках - неимоверно трудно приучить его ходить прямо, и обосновать что так гораздо удобнее и надёжнее!
Ну и ООП - это лишь некоторое удобство по выстраиванию алгоритмов. Само по себе оно 1С Предприятие не превратит в революционную новую платформу (в отличии, например, от параллельного и тем более распределённого программирования например на промисах/тасках).
Тут нужны более кардинальные изменения в принципах построения и интеграции и метаданных, и программного кода, и пользовательского интерфейса.
Поэтому я ратую не за расширение ЯП 1С8 - а за полный переход на новые ЯП, принципиально отличные от нынешнего. Тоже и с метаданными и способом их интеграции друг с другом - но этот будет уже совсем другая платформа!
В деревне программистом называют того кто умеет включать компьютер.
Полностью согласен с автором. В принципе лучший стиль программирования это А = А + ААВ + ААБ
Кто вообще использует осмысленные имена переменных, тех надо гнать из программистов.
А взамен набирать водителей автобусов.
У них будут переменные У002УО77 + Х003УМ78
Главное чтобы в глухом далеком селе программисты 1С не грустили, что им логика непонятна из-за большого количества буков.
Кстати с точки зрения не умеющего читать эта статья вообще полная фигня.
Отсюда мораль - надо не буквы писать а смайлики
За это автору и минус
Надо было написать 1С гы гы гы лол и все бы все поняли
Да и компьютеры это бесовское наваждение
Всю бухгалтерию можно спокойно вести на счетах и с налоговой проверкой проблем не будет.
Кто то не может понять логику андронного коллайдера, а кто то десятичных дробей.
У каждого свой порог вхождения
При этом на ИС есть раздел Курилка, где можно вполне запостить такую статью и собрать бурю оваций
Но никак не Приемы и методы разработки - Практика программирования
И да. Мастера старой школы НИКОГДА не писали А = А + 1
По той простой причине что
1. переменные шли нижним регистром
2. а надо было предварительно объявить и типизировать
3. односимвольные переменные рекомендовались ТОЛЬКО КАК счетчики циклов и для этого были общепринятые буквы, какие попробуйте ответить за х мин
4. было ++а, зачем оно было нужно попробуйте ответить за х мин
это вам потом пригодится чтобы понять почему ТекстЗапроса = ТекстЗапроса + ... это нехорошо даже в мире 1С
А = А + 1 можно было встретить в лабораторных студентов 1 курса идущих в армию
И я не считаю ровным местом проект на котором работает 100+ программистов
Что то вроде
public final class Integer
extends Number
implements Comparable<Integer> ?
ни на одних курсах Одинес этого ничего нет. Насколько это нужно? большой ли от этого выхлоп? И какому уровню прошраммиста 1С (Джун, мидл, синьер) эти знания соответствуют?
Кстати, в функции Инкремент несть несменное преимущество - именно в том, что она ФУНКЦИЯ
функция Инк(Знч, Пред=Истина) экспорт
предЗнч = Знч;
Знч = Знч + 1;
возврат ?(Пред<>Ложь,предЗнч,Знч);
КонецФункции
М = Массив(100);
А = ПолучитьСтартовуюПозицию();
Б = 0;
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
М[Инк(А)] = ПолучитьЗначение(Инк(Б));
А = ПолучитьСтартовуюПозицию2();
Б = 0;
Пока М[А] = неопределено Цикл
М[Инк(А)] = ПолучитьЗначение2(Инк(Б));
КонецЦикла;
ПоказатьЭто надуманный пример - но тем не менее - мне кажется он достаточно хорошо отражает суть таких подмен
В кинотеатре. — Врач! В зале есть врач? — Я врач! — Что за фигню нам показывают, коллега?
Мне и не надо чтобы все поняли.
Мне надо чтобы поняли врачи )
На Хабре люди более категоричны в суждениях.
Там считают что массовый наплыв экспертов в области программирования связан с появлением широкополосного интернета в отдаленных деревнях страны.
В принципе это видно и по комментарующим
6 лет на ИС - 0 плюсов
12 лет на ИС - 1 плюс
ну во-первых 3 обработки подбора номенклатуры в документ (в реализацию, поступление, перемещение) а аткже отдельная (!) общая форма для списания. В этой общей форме список номенклатуры (динамический список), запрос которого переопределяется динамически кодом. В обработке поступления и реализации запрос не перопределяется, в перемещении - не помню.Но помню что после поиска (поле вверху) открывается ДРУГОЙ динамический список. И еще один динамический список с динамическим запросом для характеристик.
Зачем? Вот как без знаний конфы, не помня об этом быстро разобраться в таком коде? Когда работаешь на конечника - выучил и работаешь, а если франч? Сегодня дорабатываешь типовую УНФ, завтра доработанную 2016 года, послезавтра УТ на 8.1, потом КА... Или программист должен знать все версии БСП, и все конфы сделанные на ней?
Легко!
Что то вроде
public final class Integer
extends Number
implements Comparable ?
Ну там еще на самом деле куча всякого. В общем, идите накатывать обновления на 1С
Какой кошмар!
Мы пошли дальше, у нас есть тремерный массив, где певый массив [i]- это массив простых чисел, второй массив [j] - массив простых чисел, на пересечении [i] [j] третий массив, каждый элемент которого - это результат математических операций (сложение, вычитание, умножение, процент, степень, логарифмирование итд). Все значения проиндексивароны и записаны в регистр сведений, где измерение - хеш, а показатель - индекс операции. Нам достаточно обратиться к этой базе данных с указанными действиями, она найдет хеш такого же действия, и по индексу операции найдет [i] [j] [к] значения.
Но причем здесь 1С?
ведь можно вспомнить и
(* 2 2),
и int 20h,
и даже DAD D,
но зачем?
Со статьей, кстати, согласен. Хорошо бы авторам таких "шедевров кода" посчитать трудозатраты на создание и поддержку такого кода, желательно в рублях.
Зачем Вы тут пробелы поставили - без них же занятнее (хотя что-то под С++ у меня без пробелов:
i=1;
i+=i+++++i;
Чему будет равно i?
Но это всё пережитки прошлого - такое надо запрещать прям в IDE - впрочем на практике такое почти никогда не встречается - только как головоломка, обычно в задачках на знание принципов синтаксического разбора ЯП, который такое допускает!
i+=i+++++i;
Может уже внесли коррективы с компилятор - чтобы запрещал такое! Хотя помню в институте на курсе Си таким грузили на коллоквиумах - хотя точно пример уже и не вспомню! Хотя, вот, под Python скомпилировалось и отработало!
Ну да ладно - меня больше удивило другое - это ответ если написать так
var i = 1;
i+=i++ + ++i;
C# = 5
C++ = 7
Python = 3
JS = 5
Java = 5
Kotlin = 5
Swift = не поддерживает ++
Удивительными являются результаты С++ и Python - но для C++ компиляторов свойственно выпендриваться - тут нет четкого правила разбора таких выражений и разные компиляторы могут разбирать по-разному - но я попробовал и VS и Online - везде было 7
Но почему Python выдал 3? Проигнорировал все инкременты "++" - вот такая вот особенность работы Python, в котором нет переменных (там даже такой код i+=++++i; вернёт 2 ; а такой вообще не отработает i+=i++;)
А вот 7 в C++ куда забавнее
А вот такой код
i = 1;
i = i++ + ++i;
Выдаст 5
А такой
i = 1;
i = ++i + ++i;
Выдаст 6
i += i + ++i;
И такой выдаст 6
Не логично?
Другие ЯП выдадут в первом случае 5, а во втором 4
Вот и думай после такого - а надо ли оно вообще?
Лично я бы посчитал
i = 1;
i+=i++ + ++i;
Как 7 - т.е. с моей точки зрения прав С++
У меня логика такая - считаем выражение справа
i = 1;
v1 = i; //получаем значение i до инкрементирования, та как ++ стоит справа - и является постфиксной унарной операцией, т.е. сначала нужно вернуть значение в выражение, а потом применять операцию к источнику значения) = 1
i = i + 1; //i++ = 2
i = i + 1; //++i - а тут мы сразу применяем операцию к источнику и только потом возвращаем значение из источник (уже изменённого)
v2 = i; // = 3
r = v1 + v2; // 1 + 3 = 4
И осталось добавить правый результат к левому (но там i - который к этому моменту уже изменился на значение 3)
i = i + r; // = 3 + 4 = 7
Если по-другому считать слагаемые - ведь их можно считать независимыми - ведь для сложения не важно в какой последовательности посчитаны его операнды
i = 1;
i = i + 1; //++i = 2
v2 = i;
v1 = i;
i = i + 1; //i++ = 3
r = v1 + v2 //=4
i = i + r //3 + 4 = 7
Но как в других ЯП выходит 5 - просто так отрабатывает += - значение i фиксируется = 1 до подсчёта правого выражения
i = 1;
v0 = i;
v1 = i; // =1
i = i + 1; //i++ = 2
i = i + 1; //++i = 3
r = v1 + v2; // 1 + 3 = 4
И осталось добавить правый результат к левому (но там i - который к этому моменту уже изменился на значение 3)
i = v0 + r; // = 1 + 4 = 5
Это объясняет как получается 5 и 4 в жвух других примерах соотвественно на языках, отличных от С++ - а как С++ в этих двух других примерах получает 6
Да потому что C++ считает с права на лево
i = 1;
i += i + ++i;
Это
i = i + 1;
v2 = i; // = 2
v1 = i; // = 2
r = v1 + v2; // = 4
i = i + r; // = 2 + 4 = 6
ну и
i = 1;
i = ++i + ++i;
Это
i = i + 1;
v2 = i; // = 2
i = i + 1;
v1 = i; // = 3
r = v1 + v2; // = 5
i = r; // = 5
А реально выходит 6
Причём так
i = 1;
i = i + i++;
Будет 3 = 2 + 1 Ок
А так
i = 1;
i = i + ++i;
Будет 4 = 2 + 2 Ок
И даже так
i = 1;
i = i++ + ++i;
Будет 4 = 2 + 2 Ок
Так уже
i = 1;
i = ++i + i++;
Будет 5 =/= 3 + 1 = 4
Совсем я запутался в этих выражениях....
Да и прошу прощения за оффтопик....
Унарные операции это конечно хорошо - но их применение в выражениях может быть весьма нетривиально понятным!
Вот как и в примерах выше - где-то я согласен со значениями, получаемыми в C++ - а где-то согласен со значениями в других ЯП
Ну а в 1С такое вообще не написать даже с ?-ками
По поводу ЯП - спорить не хочу - просто про С++ читал что у них там разнобой даже в рамках разных компиляторов. Другие ЯП все отработали одинаково - кроме Питона - у него самый непривычный результат!
Но дело в другом - вот даже разные комбинации операторов в разных ЯП отрабатывают не так как ожидается - в ЯП мне нравятится как одни сочетания операторов в выражении отрабатывают - в других - как другие - вот это больше всего и напрягает! Хочется порядка, и чёткого выполнения операторов! Но да - когда есть побочные эффекты - с этим всё сложно становится! Но инкремент/декремент - уж больно полезные операторы - и часто используемые в ЯП где они есть.
По мне так в настройках проекта должна быть опция - как считать выражения - слева на право или справа на лево. И ЯП обязательно должны быть выделены функции, с побочным эффектом (когда значение передаётся по ссылке - это уже сразу намёк на побочный эффект, в случае надобности - можно помечать это отдельно или наоборот помечать - что даже при наличии передачи по ссылке - функция не имеет побочного эффекта; аналогично - некоторые операторы не являются симетричными - для них тоже важна чёткая последовательность - это тоже должно быть помечено) - тогда если выражение не имеет побочного эффекта в своих членах - то его оптимизатор ещё может как-то оптимизировать по своему усмотрению - даже распараллеливать вычисления. Но если пробочки есть - то только прямое вычисление согласно заданному направлению в настройках - всё должно быть под контролем программиста и он должен чётко знать об этих нюансах!
Соответственно все операторы и функции должны вычисляться в строгой последовательности.
Не думаю что это проблема - наоброт - обычно как раз на этих не чистых функциях и выстраивается сложная логика логическихъ выражений - что, конечно, не есть хорошо!
Лично мне нравится иной подход - когда все операции над данными сводятся к двум вариантам:
1. Функции - всегда чистые (могут не иметь явного возвращаемого значения - тем самым заменяя процедуры)
2. Команды - чаще всего не чистые, но не обязательно (при этом могут неявно принимать несколько выражений, причём как левых так и правых - это задаётся в их определении; а так же могут влиять на поток выполнения)
И те и другие могут быть глобальными (или локальными в текущем контексте), так и заданными у объектов (так сказать - персонально определённые, в этом случае переопределяющие глобальные, но не локальные).
Все остальные операции над данными сводятся только к последовательному применению данных объектов.
Из ключевых слов - возможно стоит только оставить операции определения различных сущностей и выделения ветви кода (отдельного потока инструкций) - всё остальное по сути сводится к командам.
Соответственно все мат. операции лучше считать командами - значит не стоит из считать 100% чистыми!
Так же всякие циклы и условные операторы - это всё тоже нужно считать командами - они тоже не 100% чистые!
Но команда может быть помечена - как 100% чистая - тогда это даст возможности компилятору к оптимизации её применения!
Пример:
def command send (message) -> Console.Writeln(message)
(1..100) -> elm % 2 ? elm send "odd" ~> elm send "even"
Вот лучше такой - как бы правильно развернуть запись
i+=i+++++iкоторую без пробелов почти ни один их протестированных мною ЯП вообще не компилирует (что я считаю правидльно, что не компилируют - несколько не буквенно-цифровых операций подряд ВСЕГДА должны быть друг от друга отделены символами табуляции или буквенно-цифровыми элементами - искусственное ограничение дающее понимание - ну или IDE самодельна тут же в конце ввода (строки) принудительно расставить пробелы - как запись поймёт анализатор) - иначе они должны восприниматься как единая операция (в данном случае "+++++" - если такая будет определена - то она имеет право на существование)
Я считаю, что такие короткие математически операции (хотя не обязательно могут быть арифметическими - ведь i - формально может быть любого типа, строкой, коллекцией, портом ввода-вывода - главное чтобы данные операции над данным типов и экземпляром были определены) вполне себе допустимы и легко читаемы (i += i++ + ++i), тем не менее - строго в командах это выглядело бы так:
i add getinc i add incget iи вот так если расставить скобки - согласно области действия команд (тут add правая команда с операндом, а две другие левые команды без операнда - это всё помечено при определении команд)
i add ( (getinc i) add (incget i) )Каждая такая команда является атомарной (помечена при определении) - это важно при параллельном выполнении (либо оптимизируется отдельной инструкцией процессора, либо блокирует объект на время выполнения от других параллельных потоков).
В итоге на высоком уровне абстракции это всё может транслироваться в следующий поток инструкций
v1 = memmngr.newmem(typeof(i))
typeof(i).getinc(i)
set v1
v2 = memmngr.newmem(typeof(i))
typeof(i).incget(i) v2
typeof(i).add(v1,v2)
typeof(i).add(i,v2)
memmngr.freemem(v1)
memmngr.freemem(v2)
ПоказатьЗдесь уже команды превращаются просто в статические вызовы подпрограмм (функций)
И все они не является чистыми!
Подразумевается, что все команды есть у тип экземпляра i - используются его собственные реализации команд
(v1,v2 - адреса ячеек памяти - я тут не уточняю как и где они выделяются и освобождаются, все операции идут через неявную буферную ячейку результата)
Функция Инкремент(а)
а = а + 1;
Возврат а;
КонецФункции
Это все хорошо в исследовательских целях, в институте или в качестве развлечения, но не в бизнес-программировании.
Тогда уж давайте упомяну то - что я за то, что все программы (алгоритмы) которые можно встретить в учетной системе лучше сразу разделить на несколько направлений программирования - отличных по ЯП и правила построения кода:
1. Алгоритмы обработки данных
2. Алгоритмы взаимодействия с системами хранения данных
3. Алгоритмы построения пользовательского интерфейса
4. Алгоритмы описания нечёткой логики для AI системы
5. Алгоритмы описание бизнес логики прикладного уровня
6. Алгоритмы описания самотестирования
У каждого направления свои цели и свои подходы в написании алгоритмов!
Но замечу, что математические операции так или иначе свойственны всем направлениям. И операция инкремента вполне себе имеет право на существование как математическая операция. Хотя таковой не совсем является - ибо наделена побочными эффектами. Просто так уже сложилось в среде многих ЯП - эта операция очень старая и очень популярная! Но в сложных выражениях как "i+=i++ + ++i" она встречается крайне редко.
Но замечу, что при грамотном современном проектировании ЯП (и его базовых библиотек) - потребность в этой операции действительно можно свести к минимуму - но пока наиболее частое применение это что-то вроде такого кода
arr = new Array[src.Count];
var i = 0;
while src.Next()
{
arr[i++] = src.Data;
}
Просто экономия листинга кода без снижения его понятности - часто такие простые циклы ещё пишу в одну строку - и я не вижу в этом ничего плохого
arr = new Array[src.Count];
var i = 0;
while src.Next() arr[i++] = src.Data;
Коненчо - можно было это сделать циклом for (
arr = new Array[src.Count];
for (var i = 0 ; i < src.Count ; i++)
{
src.Next();
arr[i] = src.Data;
}
Но мне такой код нравится меньше
Хотя можно было бы и так
arr = new Array[src.Count];
for (var i in (0..src.Count) )
{
src.Next();
arr[i] = src.Data;
}
Но мне больше нравится вот такая фантастическая форма
arr = new Array[src.Count];
(0..src.Count) -> next src, arr[i] = src.Data;
Ну и в идеале так
arr = Array();
(src.Data) -> arr
Хитрый декларативный код выше направляет поток src (выделяя из него поле Data) в поток arr - определение размера ту не важно - они оптимизируются при кодогенерации - так что тут в итоге буде что-то типа первого примера с циклом "while".
Вот так должен выглядеть такой алгоритм на ЯП бизнес логики по моему мнению - коротко - минимум деталей к тонкостям устройства обращения к потокам и знания того, как они устроены - просто инструкция - требующая переместит (скопировать) указанное содержимое из одного источник в другой. В таком коде потребность в операциях "++" будет минимальна (но я бы всё равно их ввёл бы - скорее как дань традиции большинству ЯП).
Ну и как написал выше - я за то, чтобы отделять функции от команд - функции лучше всегда считать чистыми - без побочных эффектов. Команды - всегда считать априори возможно имеющие побочные эффекты. Тогда операция "++" не должна быть функцией - это команда ("++" - это синтаксическая обёртка для вызова атомарной команды "getinc" или "incget" - как я и показал в предыдущем посте) с побочным эффектом (на то она и команда - она вызывает внутренний процесс в объекте своего применения).
Как и в примере выше команда "next" - для смещения позиции менеджера потока на следующий элемент - тоже команда с побочным эффектом - но про команды не стоит говорить "побочный эффект" - это скорее целевое действие!
И ещё - замечу - что "++" - это атомарная команда - т.е. неделимая! Это важно в ЯП, когда есть параллельные потоки (какими бы они не были - реальными потоками ОС или их эмуляцией на корутинах - квазипотоки с управляемым самой платформой ЯП переключением активного контекста выполнения). Такая операция не может быть прервана переключением контекста выполнения - что исключает ошибки параллельного доступа к неполностью сформированному значению. В машинных командах для такой операции даже есть отдельная инструкция процессора. Виртуальные машины тоже выполняют её всегда целиком!
Конечно такую запись "i+=1" и такую "i=i+1" тоже можно оптимизировать в атомарную инструкцию - но вот в большинстве ЯП они не являются выражением - ведь суть атомарной инструкции инкремента в том, чтобы не просто изменить значение - но и вернуть (либо строго предыдущее, либо строго новое, даже если оно параллельно меняется в другом потоке) - поэтому инкремент это не процедурная команда - а функциональная - возвращающая гарантировано точный результата, согласно своему описанию!
Ну а современный мир программирования - это асинхронность и распределённость - и следующая платформа 1С не должна упустить этот тренд в своём развитии!
Откуда такая тенденция пошла - токсично отвечать оппоненту - написавшему пост или статью сразу приписывают ярлык "нытика"?
Мы же не считаем, что вы ноете или оправдываете глупость с умным видом в этом месте:
Вы просто высказали свое мнение, а мы просто его прочитали без навешивания на вас ярлыков.... Это так легко - просто делиться мнениями....
Блин на изменение дается 30 минут всего.
Короче, не хотел обидеть автора. Просто хотел высказаться в защиту усложнения конфигураций и считаю, что в 1с идут правильным путем
Ах да, да. Статья фигня, околопредметная болтовня, не понимаю, откуда столько плюсов. И комменты флуд сплошной. Беспредел, короче.
но он не "ноет" ... само слово "ноет" и "нытик" - токсично на форумах ...
так и про меня можно написать - что я "ною", что кто-то употребляет слово "ноет".....
а можно без этого слова взаимодействовать?
И конспирология вида - они усложняют, что бы было сложно и оттого дорого - это какой-то детский максимализм.
В итоге - придётся ждать когда старая гвардия внутри компании 1С окончательно отойдёт от дел - главное чтобы новая волна к тому времене не успела интеллектуально разложиться и перегореть - вот тогда и стоит ждать новых веяний и, вероятно, новую платформу 1С Предприятие 9 (или под другим именем) - ранее кардинально менять ЯП внутри 8-ки никто не будет! Хотя, небольшие изменения в ЯП можно было бы сделать - но это уже будет как минимум 8.4 - а даже её что-то не торопятся выпускать (хотя даже анонсировать успели, как успели уже поскорее забыть про эти анонсы). Хотя... вон асинхронные (почти бесполезные в нынешнем виде) вызовы всё-таки внесли в ЯП не меняя версию редакции платформы 8.3 на 8.4 - что в очередной раз говорит, что со скоростью улитки ЯП 1С всё-таки развивается, не меняя редакции - но по мне - так это всё как мёртвому припарки!
Аналогично - в последнем релизе платформы (8.3.20) внесли новые функции в язык запросов (а несколько лет назад - даже новые синтаксические конструкции) - развитие есть - или это только видимость развития - на многочисленные стоны и жалобы сообщества?
1. Типизированный - для описания "математических" алгоритмов обработки данных и всякого рода относительно низкоуровневого взаимодействия.
2. Императивно-функционально-декларативный - для описания логики выполнения и взаимодействия процессов с высоким уровнем абстракции. Эдакий ЯП 4-го или в идеале уже 5-го поколения!
Если с первым ЯП более-менее понятно - для меня тут сейчас некий "условный" эталон - это С# или Kotlin или Python или TypeScript.
То второй - должен сохранить трендовую структуру императивно-функционального стиля программирования - но являться декаларативным (не исполняться на прямую, а анлизтироваться умным AI-компилятором-транслятором) с целью получения итоговой логики исполнения - и уже на её основе долже генерироваться конечный код (с применением базы знаний эффективных шаблонов алгоритмов и статистики реального исполнения алгоритмов в конечной прикладной среде) - с максимальной оптимизацией (более того такой итоговый код может даже динамически меняться со временем - по факту накопления реальной статистики и улучшению шаблонов кода).
Но это не всё.
На таком ЯП и исходный декларативный код будет достаточно абстрактным - не конкретным - часто оперирующим не полностью определёнными сущностями - например группой полей (не зная фактического состава) - или интефейсами (не зная какие реальтные объекты на за ними скрываются, и как вообще эти объекты собираются - из скольких частей) или требованиями к выборке данных - не зная фактического запроса к СУБД!
И это и усложнение и упрощение одновременно!
Усложнение в том - что нет чёткого представления о фактического коде - он полностью динамический! Отладка его может бытть затруднительной.
Упрощение в том - что код описывается условно декларативно, т.е. есть некая единая структура (но не обязательно единственная) мест формирования этого кода - и эта структура должна иметь документацию - тогда весь код легко анализировать и модифицировать блочной. Ну а ставка на абстракцию данных - тоже на руку - не при модификации не нужно заботиться о всех местах - нужно модифицировать только место определения или расширения абстракции - а все места её обрабатывающие останутся неизменным! Ну а AI-анализ освободит от необходимости глубокой ручной оптимизации и проблемы простого, разбросанного, но не оптимального кода - AI-компилятор сам всё соберёт в единое оптимальное целое, проанализировав весь код целиком, а не только отдельные его части независимо друг от друга.
Так что моё мнение - сборка кода из разных мест - это не такая уж плохая идея - тут, главное, реализовать это эффективно и понятно (документировано)!
Ну а для упрощения программирования нужно ещё и IDE развивать - сейчас даже в Visial Studio IDE - достаточно примитивна (не говоря уже об EDT или 1С Конфигураторе) - есть ещё много куда можно расти и развиваться, чтобы сделать работу программиста проще даже при усложнении ЯП. Так же нужно развивать о специальные интеллектуальные средства анализа кода - позволяющие выявлять и оптимизировать узкие и ошибочные места! В любом ЯП с этим есть где развернуться!
Но это уже совсем другая тема!
А мы перепишем код так что один из параметров будет обрабатываться как структура а не значение определённого типа. И всё. Наши колёса такие палки ломают на раз.
Но не таким который матерый и знает как страной управлять надо, а начинающим, который пока только может все костерить.
Однако стало понятно для чего автор написал САРКАЗМ.
Большая часть не только не понимает ООП, она просто полностью в ауте.
Офигеть раздел Приемы и методы разработки - Практика программирования
Куда модераторы только смотрят
Но приуныл не от того что такие статьи неистово плюсуют. Это как раз мне на руку. Чем больше пишущих А = А +1; тем больше з/п у пишущих по другому.
Раздел этой статьи меня беспокоит.
А для жалоб на тяжкую долю есть рубрики другие
По моему человек знакомый с отладчиком способен понять любую глубину вызовов функций
Позволю себе не согласиться, коллега. Как известно, плохой программист за год работы создаёт дополнительное рабочее место. Так вот, эти плохие программисты, вкупе с ростом спроса создали такое количество рабочих мест, какое не покрыть ничем. И если богатые страны и компании могут себе позволить рекрутировать индусов, то у нас такой возможности нет, а Киргизия с Таджикистаном, почему-то программистов не поставляют. Так что эти игры закончатся плохо.
Отладку тоже можно сделать в виде графов - схем, хотя бы как mind map.
или например вот так
...Посмотрел я минут 5 на эту адскую паутину из десятков квадратиков, ромбиков, треугольничков, из сотен стрелочек... Помедитировал... И больше про визуализацию кода никогда не думал даже. Ибо бесполезно.
Да, смотря на код типовых, особенно erp, есть четкое понимание, что ребята из команды разработки забыли золотое правило "Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте" и тупо соревнуются между отделами, кто придумает более извращенный способ сделать простую вещь.
Но неужели кто-то всерьез планирует один раз выучить язык и полсотни лет писать одно и тоже и одинаковым способом? Народ, кто знаком с "трушными" языками, есть такое где? Вон, даже Пролог, который хоронят уже лет 40, до сих пор развивается и меняется
Теперь разработчику при работе с элементами формы, надо учитывать, что пользователь может изменить форму. Многие про это помнят? Я до сих пор часто вижу, что для группы устанавливают Доступность = Ложь, рассчитывая, что гарантированно будут недоступны все подчиненные элементы. А как в таблице формы сделать чтобы все колонки таблицы имели цвет фона, отличный от стандартного? Крупные заказчики хотят иметь интерфейс системы в соответствие с утвержденным корпоративным стандартом.
Как раз на прошлой неделе сожалел что слоев не осталось - понадобилось сделать чтобы на нескольких страницах отражался табличный документ (единый), а на остальных - таблицы формы.
Не помню, чтобы у кого-либо вызывало проблемы рисование макета. У меня этим занимались даже пользователи (не программисты) - заказчики отчетов. Вот проблем с получением нужного вида отчетов на СКД помню предостаточно. Зато получившийся макет нагляден, его легко использовать и поддерживать, в нем логичная схема работы с расшифровками, его можно использовать для ввода данных.
Вряд ли кто-то против прогресса, но являются ли изменения действительно прогрессом? Не надо забывать, что мы все-таки в основном занимаемся бизнес-программированием, а не академическим. Не стоит тащить в 1С все без разбора. Я в свое время много писал на asm x86, мне очень нравился C и Lisp, сейчас поглядываю на haskell, но не думаю что в 1С так уж необходим прямой доступ к памяти и регистрам процессора или работа с функциями высших порядков.
СКД до сих пор причиняет мне боль) Стоит только отойти от простейшей таблицы или списка. Особенно в обычных формах
(97)
Да нет, конечно, не являются. И никто этого не утверждает. Как обычно это и бывает при поиске своего пути - проблем много. Но если дать волю всем, кто кричит, что он лучше всех знает что нам надо, то получим басню про лебедя, рака и щуку. Радует, что 1С активнее развивает платформу, есть шанс, что неудобное само отомрет))
Сперва процедуры и функции были как "Война и мир". Разбираться в таком длинном коде проблематично и главное он совершенно не гибок. Кто-то подсказал, что есть "декомпозиция", но как ей пользоваться не сказал. Итог - имеем огромную кучу маленьких процедур. Понять целостную картину алгоритма стало еще тяжелее.
Правда она посередине...
Было ():
Функция СведенияОВнешнейОбработке() Экспорт
ПараметрыРегистрации = Новый Структура;
МассивНазначений = Новый Массив;
ПараметрыРегистрации.Вставить("Вид", "ДополнительнаяОбработка");
ПараметрыРегистрации.Вставить("Назначение", МассивНазначений);
ПараметрыРегистрации.Вставить("Наименование", НСтр("ru = '" +Метаданные().Представление()+ "'"));
ПараметрыРегистрации.Вставить("Информация", НСтр("ru = '" +Метаданные().Комментарий+ "'"));
ПараметрыРегистрации.Вставить("БезопасныйРежим", Истина);
ПараметрыРегистрации.Вставить("Версия", "1.0");
ТаблицаКоманд = ПолучитьТаблицуКоманд();
ДобавитьКоманду(ТаблицаКоманд, "Открыть форму", "ОткрытиеФормы"+Метаданные().Имя, "ОткрытиеФормы", Ложь, "");
ПараметрыРегистрации.Вставить("Команды", ТаблицаКоманд);
Возврат ПараметрыРегистрации;
КонецФункции
Функция ПолучитьТаблицуКоманд()
Команды = Новый ТаблицаЗначений;
Команды.Колонки.Добавить("Представление", Новый ОписаниеТипов("Строка"));
Команды.Колонки.Добавить("Идентификатор", Новый ОписаниеТипов("Строка"));
Команды.Колонки.Добавить("Использование", Новый ОписаниеТипов("Строка"));
Команды.Колонки.Добавить("ПоказыватьОповещение", Новый ОписаниеТипов("Булево"));
Команды.Колонки.Добавить("Модификатор", Новый ОписаниеТипов("Строка"));
Возврат Команды;
КонецФункции
Процедура ДобавитьКоманду(ТаблицаКоманд, Представление, Идентификатор, Использование, ПоказыватьОповещение = Ложь, Модификатор = "")
НоваяКоманда = ТаблицаКоманд.Добавить();
НоваяКоманда.Представление = Представление;
НоваяКоманда.Идентификатор = Идентификатор;
НоваяКоманда.Использование = Использование;
НоваяКоманда.ПоказыватьОповещение = ПоказыватьОповещение;
НоваяКоманда.Модификатор = Модификатор;
КонецПроцедуры ПоказатьСтало:
Функция СведенияОВнешнейОбработке(ВерсияБСП="") Экспорт
Перем ПараметрыРегистрации, ОписаниеКоманды;
//Структура для ответа
ПараметрыРегистрации = ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке(ВерсияБСП);
ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиДополнительнаяОбработка();
ПараметрыРегистрации.Вставить("Наименование", НСтр("ru = '" +Метаданные().Представление()+ "'"));
ПараметрыРегистрации.Вставить("Информация", НСтр("ru = '" +Метаданные().Комментарий+ "'"));
ПараметрыРегистрации.Вставить("Версия", "2.0.0.2");
//Команда "ОткрытиеФормы"
ОписаниеКоманды = ПараметрыРегистрации.Команды.Добавить();
ОписаниеКоманды.Представление = "Открыть форму """+ПараметрыРегистрации.Наименование+"""";
ОписаниеКоманды.Идентификатор = Метаданные().Имя;
ОписаниеКоманды.Использование = "ОткрытиеФормы";
ОписаниеКоманды.ПоказыватьОповещение = Ложь;
ОписаниеКоманды.Модификатор = "";
Возврат ПараметрыРегистрации;
КонецФункции ПоказатьПримечание 1: "ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиДополнительнаяОбработка()" вместо просто "ДополнительнаяОбработка" - да, это удобно. Синтаксис-помощник работает и дает больше шансов не налажать с написанием.
Примечание 2: не хватает "ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработкеДобавитьКоманду(...)", хотя может код будет выглядеть менее наглядно.
//---
Ну и мой вариант (если не знаешь, будет ли в конфе БСП, если нет - то чтобы хоть ошибок не было):
Функция СведенияОВнешнейОбработке(ВерсияБСП="") Экспорт
Перем ПараметрыРегистрации, ОписаниеКоманды;
//Структура для ответа
ПараметрыРегистрации = Новый Структура;
ПараметрыРегистрации.Вставить("Вид", "ДополнительнаяОбработка");
ПараметрыРегистрации.Вставить("Назначение", Неопределено);
ПараметрыРегистрации.Вставить("БезопасныйРежим", Ложь);
//ПараметрыРегистрации.Вставить("ВерсияБСП", "2.0.1.3"); //БСП не требуется
ПараметрыРегистрации.Вставить("Наименование", НСтр("ru = '" +Метаданные().Представление()+ "'"));
ПараметрыРегистрации.Вставить("Информация", НСтр("ru = '" +Метаданные().Комментарий+ "'"));
ПараметрыРегистрации.Вставить("Версия", "2.0.0.2");
ПараметрыРегистрации.Вставить("Команды", новый ТаблицаЗначений);
//Колонки команд
ПараметрыРегистрации.Команды.Колонки.Добавить("Представление", Новый ОписаниеТипов("Строка"));
ПараметрыРегистрации.Команды.Колонки.Добавить("Идентификатор", Новый ОписаниеТипов("Строка"));
ПараметрыРегистрации.Команды.Колонки.Добавить("Использование", Новый ОписаниеТипов("Строка"));
ПараметрыРегистрации.Команды.Колонки.Добавить("ПоказыватьОповещение", Новый ОписаниеТипов("Булево"));
ПараметрыРегистрации.Команды.Колонки.Добавить("Модификатор", Новый ОписаниеТипов("Строка"));
//Команда "ОткрытиеФормы"
ОписаниеКоманды = ПараметрыРегистрации.Команды.Добавить();
ОписаниеКоманды.Представление = "Открыть форму """+ПараметрыРегистрации.Наименование+"""";
ОписаниеКоманды.Идентификатор = Метаданные().Имя;
ОписаниеКоманды.Использование = "ОткрытиеФормы";
ОписаниеКоманды.ПоказыватьОповещение = Ложь;
ОписаниеКоманды.Модификатор = "";
Возврат ПараметрыРегистрации;
КонецФункции Показатьпервый год:
Скрытый текст |
|---|
| println('Hello World') |
Через пару лет:
Скрытый текст |
|---|
| char *message[] = {'Hello ','World'};
int i; for(i = 0; i < 2; ++i) printf('%s', message[i]); printf(' '); |
еще через пару лет:
Скрытый текст |
|---|
| #include
class string { private: int size; char *ptr; public: string() : size(0), ptr(new char('*')) {} string(const string &s) : size(s.size) { ptr = new char[size + 1]; strcpy(ptr, s.ptr); } ~string() { delete [] ptr; } friend ostream &operator << (ostream &, const string &); string &operator = (const char *); }; ostream &operator << (ostream &stream, const tring &s) { return(stream << s.ptr); } string &string::operator = (const char *chrs) { if(this != &chr) { delete [] ptr; size = strlen(chrs); ptr = new char[size + 1]; strcpy(ptr, chr); } return(*this); } int main() { string str; str = 'Hello World'; cout << str << endl; return(0); } |
год 10й...:
Скрытый текст |
|---|
| println('Hello World') |
....
все это к чему. Есть хорошая фраза: "Горе от ума". эволюция БСП огорчает. будем надеяться, что этот "10й год" где-то вот совсем рядом
Цикломатическая сложность алгоритмов как БСП так и новых типовых формально очень высока: большое число уровней вложенностей, ветвление вызовов, закладки для переопределения типовых методов (эмуляция ООП).
Но с другой стороны, когнитивная сложность каждого отдельно взятого алгоритма существенно снизилась, и теперь, если вы умеете не только читать, но и представлять в уме структуру алгоритма при чтении его фрагментов, то чтение программы в сумме становится более простым. А если прибавить к этому знание принципов по которым строится архитектура конкретного решения, то задача становится очевидно проще, чем чтение функций на 2к+ строк. Сложность внесения изменений, при этом, стала ниже по тем же причинам.
Но это всё в теории и лишь для некоторых подсистем, типа подсистемы печати и подобных БСП-ных полезняшек. На практике же, если системную библиотеку БСП, судя по всему разрабатывают вменяемые люди, задумывающиеся о том, что и как они делают, то прикладной код типовых зачастую разрабатывают
Таким образом, в реально существующих типовых, действительно есть плохая архитектура, не только плохой код. И претензии автора, пусть и шуточные, имеют под собой вполне реальную почву. Но наблюдая за эволюцией типовых в целом, не могу не отметить существенный прогресс в подходах. Давным-давно разработанная мною библиотека и отдельные подсистемы в ней постепенно модифицируется или просто просто режется из поставки для новых типовых по одной просто причине - уже реализовано в БСП или в конкретной типовой. Жаль, что спустя более чем 10 лет, но главное, что процесс идёт.
Посоветовать программистам могу лишь одно - учитесь быть программистами. Просто кодить может абсолютно любой человек умеющий писать.
Вечная бета для того чтобы причаститься использования которой еще надо и железо обновить себе.
Рейтинг: 587
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1561877
Создание 03.12.21 16:30
Обновление 03.12.21 16:30
Просмотры 11190
Загрузки 0
Рейтинг
75
Комментарии 161
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
