Совершенный коТ (Cat complete)
Разработка - Рефакторинг и качество кода
Название статьи обыгрывает известное название книги Steve McConnell «Code complete». Статья отличается от множества других статей на подобную тему: текста не видно, а картинки все время двигаются. Директор нашего департамента утверждает, что сейчас среди людей преобладает клиповое мышление. Посмотрим, насколько эта статья приглянется читателям.
Первый клип посвящен объектному чтению. Это действительно очень плохой стиль программирования. Но есть хорошие новости: я научился находить в технологическом журнале все случаи объектного чтения, которые мешают работе программы. Такие запросы используют ключевые слова SELECT…Version. Запросы, которые пишут программисты, версию объекта не используют. Подробнее - infostart.ru/public/825405.
Второй клип – пожалуйста используйте форматирование. Кроме волшебных клавиш Shitf+Alt+F пригодится сочетание Shift+Tab сдвигать влево текст запросов, созданных конструктором. Если текст запроса формируется динамически, изменяется - пожалуйста, сделайте чтобы его можно было открывать конструктором для просмотра и проверок ошибок.
Синтаксические ошибки в коде программы – также как в деловой переписке свидетельствуют о незаинтересованности корреспондента. Кстати, S. McConnell глава «Форматирование и стиль», основные тезисы:
- Зрительное и интеллектуальное наслаждение, получаемое от хорошо отформатированного кода, — удовольствие, которое способны оценить лишь немногие непрограммисты
- Основная теорема форматирования гласит, что хорошее визуальное форматирование показывает логическую структуру программы
- В сложных логических выражениях размещайте каждое условие на отдельной строке
- Избегайте операторов goto
- Длина строки выражения не должна превышать 80 символов (В современной 1С – 120 )
- Используйте пробелы около скобок ( () ), чтобы сделать читаемыми логические выражения
- Что делать с частью выражения, переносимой на следующую строку
- Не выравнивайте правые части выражений присваивания (Сейчас нет единой позиции по этому вопросу. Но мне импонирует Code complete)
- Размещение каждого оператора на отдельной строке
Кроме этого, метаданные (Справочники, Документы, Регистры…) в дереве необходимо сортировать. Так гораздо аккуратнее. Реквизиты объектов можно оставить без сортировки. Исключение: нельзя сортировать подписки на события !! Потому что порядок выполнения подписок зависит от их положения в дереве метаданных, см //infostart.ru/public/554424/. Самая плохая идея - сортировать реквизиты регистров сведения (накопления).
Третий клип. Константу использовал для примера. Уверен, что Вы сможете придумать более элегантный способ избежать хардкодинга.
Чтобы вы правильно понимали, из двадцати лет работы программистом, восемнадцать лет я использовал короткие, неинформативные имена переменных. Потребовался толчок (Доброе слово и пистолет), чтобы я начал задумываться об их именах. Кстати, S. McConnell глава «Сила имен переменных», основные тезисы:
- Имя должно полно и точно описывать сущность, представляемую переменной.
- Аббревиатуры, сокращения нежелательны (ниже идет список рекомендованных сокращений).
- Короткое имя означает, что переменная будет использоваться в одной-двух строках. Многие опытные программисты вообще не используют имена вроде i.
- Чем шире область применения переменной, тем имя должно быть длиннее.
- Префикс - тип переменной в имени можно указывать или нет (По стандартам 1С ИТС – нет)
- Не нужно использовать сокращения, допускать грамматические ошибки.
- Использовать для переменных предопределенные слова, например "Записать"
Именам функции (процедуры) посвящен раздел https://its.1c.ru/db/v8std#content:647:hdoc. Если вкратце, имена не должны содержать префикс или иной намек на возвращаемый тип данных, аргументы функции (процедуры) при возможности сохранять в структуре значений, которая будет единственным аргументом, наименование функции (процедуры) должно быть настолько информативным, чтобы не было нужды в дополнительном комментарии. Кстати, S. McConnell глава «Самодокументирующийся код», основные тезисы:
- Задача документирования … во многом решается за счет хорошего стиля программирования (правильные имена переменных и функций).
- Комментарии иногда полезны, иногда - нет (перечислены случаи pro et contra. И это не намек на популярную игру, а обычная латынь. Не латунь, а латынь.)
- Не комментируйте хитрый код — перепишите его
В последнее время из имени стали убирать часто-используемое слово «Получить».
В планах – добавить клип про создание форм пользовательских интерфейсов. Пока перечислю основные тезисы:
- Рекомендуется для всех форм самостоятельно настраивать расположение реквизитов, их растягивание (по умолчанию реквизиты не должны растягиваться по горизонтали), расположение и выравнивание.
- Автоматическое расположение реквизитов допускается для форм простейших объектов (например, справочник из Наименование + Код)
- Форма для отчетов на основе СКД как правило используется из дерева метаданных Общие формы -ФормаОтчета. Это принесет дополнительные бонусы: регистрация в замерах производительности, аккуратный выбор периода отчета, стандартное редактирование настроек, обработчики реквизитов формы. В случае, если необходимо внести изменения, копируем форму из дерева метаданных общие формы в отчет, назначаем основной и изменяем.
- Для ПолныхПравПрограммистов всегда должны быть доступность и видимость всех реквизитов, если задача не подразумевает обратное. Исключение составляет реквизит номер.
- Все реквизиты шапки размещаются согласно стандартам разработки 1С Стандарт 1С: Командная панель формы документа.
- Синоним поля Дата назначается «от». Длина поля Дата 14 символов.
- Ширина поля Номер определяется, исходя из длины номера экспериментальным путём – так, чтобы все цифры помещались в поле, и при этом не было пустого пространства.
- Итоги документов размещаются согласно стандартам разработки 1С Стандарт 1С: Итоги в документах. Рекомендуется использовать стандарт в качестве образца расположения. Цветовое решение может отличаться, ввиду того, что используется другой интерфейс. За основу можно взять следующее оформление (цвет фона Web Дымчато-белый)
- В свойствах всех реквизитов шапки необходимо снимать признак Растягивать по горизонтали. При необходимости задания ширины элементов, отличной от сформированной платформой, задать значение вручную.
- Для всех документов, которые будут создаваться пользователями в количестве, большем нескольких штук, по умолчанию добавлять комментарий и автора (Ответственный). Ответственный или автор – определяется программистом самостоятельно, в зависимости от конкретной задачи. Оформление реквизитов выполняется в соответствии со стандартом Стандарт 1С: Поля Ответственный и Комментарий. В отличие от реквизитов шапки, поле комментарий может иметь признак Растягивать по горизонтали.
- Модули форм оформляются через области, используя стандартные и, при необходимости, свои.
#Область ОбработчикиСобытийФормы
#КонецОбласти
#Область ОбработчикиСобытийЭлементовФормы
#КонецОбласти
#Область ОбработчикиСобытийЭлементовФормыНаСервере
#КонецОбласти
#Область ОбработчикиКоманд
#КонецОбласти
#Область СлужебныеПроцедурыИФункции
#КонецОбласти
Отдаю себе отчет, что тема хорошего кода – высокохоливарная, поэтому конструктивные комментарии приветствуются, поощряются SM и включаются в статью. Заранее спасибо.
Порядок комментирования программного кода и изменений
1. Помещение в хранилище изменений
Любые изменения, помещаемые в хранилище, должны сопровождаться комментарием с произвольным описанием вносимых в хранилище изменений.
Пример описания вносимых изменений:
1.1. Добавлен отчёт ПРЕФИКС_Продажи
1.2. В типовой документ ПТиУ добавлен реквизит «ПРЕФИКС_Акция» и его обработка в модулях.
2. Добавление Нового функционала
Новые процедуры/функции, блоки кода должны сопровождаться комментарием в случае внесения изменений в чужой или типовой блок/модуль/объект. Для полностью своих объектов комментировать каждую процедуру не требуется.
Рекомендуется для быстрой вставки комментариев использовать текстовые Шаблоны.
2.1. Новые переменные в разделе описания переменных
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание задачи - опционально>
2.2. Перем НоваяПеременная1, НоваяПеременная2;
//- ПРЕФИКС <Фамилия И.О. разработчика>
2.3. Новые процедуры/функции в типовых модулях
Добавляются с префиксом «ПРЕФИКС_», кроме добавления стандартных обработчиков, описанных в п.2.8.
Новые процедуры/функции в модулях, разработанных самим разработчиком
Не нуждается в комментировании
2.4. Код внутри типовых модулей и в процедурах/функциях, разработанных другими разработчиками
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание кода - опционально>
код
//- ПРЕФИКС <Фамилия И.О. разработчика>
Описание кода рекомендуется использовать в случаях сложных алгоритмов и при необходимости обратить внимание других разработчиков на некие особенности данного кода/блока/процедуры/запроса.
2.5. Код в процедурах/функциях, разработанных самим разработчиком
Не нуждается в комментировании
2.6. Удаление существующей процедуры/функции – типовой или разработанной другим разработчиком
Программный код тела, начала и окончания процедуры или функции должен быть закомментирован, а перед началом этой процедуры или функции и после его/ее окончания должен быть добавлен комментарий:
//+ ПРЕФИКС Комментирование <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание задачи - опционально>
//Процедура ИмяПроцедуры(ПараметрыПроцедуры)
// тело процедуры или функции
//КонецПроцедуры
//- ПРЕФИКС Комментирование <Фамилия И.О. разработчика>
2.7. Удаление существующей процедуры/функции, разработанной самим разработчиком
Не нуждается в комментировании
2.8. Если для решения задачи необходимо создать стандартный обработчик существующего в типовой конфигурации элемента формы или стандартный обработчик модуля объекта (ПередЗаписью, ПриЗаписи и т.п.), сначала стандартными средствами создается обработчик, а затем внутрь его помещается новый функционал по правилам п.1.4. То есть например, если в модуле объекта необходимо вставить код в процедуру ПриЗаписи(), которой нет, то результат будет следующий:
Процедура ПриЗаписи(Отказ)
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <описание задачи - опционально>
код
//- ПРЕФИКС <Фамилия И.О. разработчика>
КонецПроцедуры
3. Изменение существующего типового функционала или функционала, написанного другим разработчиком.
//+ ПРЕФИКС Комментирование <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Причина изменения>
// старый код
//- ПРЕФИКС Комментирование <Фамилия И.О. разработчика>
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание изменений - опционально>
новый код
//- ПРЕФИКС <Фамилия И.О. разработчика>
4. Любые добавления в нетиповой, исправленный, добавленный программный код, написанный другим разработчиком, комментируются в соответствие с п.2.4.
5. Создание новых объектов
При именование новых объектов конфигурации, новых реквизитов, форм, макетов, табличных частей должен использоваться префиксом «ПРЕФИКС_»
Все объекты конфигурации должны сортироваться в алфавитном порядке:
сначала типовые объекты, потом добавленные с префиксом «ПРЕФИКС_» и другими префиксами, если такие будут. При добавлении нового объекта рекомендуется сразу его передвигать по дереву в порядке сортировки.
5.1. При создании новых объектов конфигурации
- префикс «ПРЕФИКС_»
ПРЕФИКС_Справочник;
ПРЕФИКС_Документ.
5.2. При создании новых реквизитов, форм, макетов, табличных частей в типовые объекты:
-префикс «ПРЕФИКС_»
5.3. При создании новых реквизитов, форм, макетов, табличных частей в нетиповые объекты
- префикс не нужен
6. Использование перевода строки
В случае добавления кода в существующую строку типового, измененного, нового фрагмента программного кода допускается использовать перевод строки:
6.1. Вставка разделителей текста (пробел, перевод строки)
Процедура ВыполнитьОперацию(ТиповойПараметр1
//+ ПРЕФИКС <Фамилия И.О. разработчика> от <дд-мм-гггг>. <Описание задачи - опционально>
,Парам2
//- ПРЕФИКС <Фамилия И.О. разработчика>
,ТиповойПараметр3) Экспорт
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 353 1 nedomolkov.ivan 1
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 374 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 486 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 518 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 455 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 529 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 3472 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 325 Ninel_S 0
При объектном чтении ( Например, ДокументСсылка.Номер )
из СУБД считываются не только реквизиты объекта, но (если есть)
и все табличные части и все реквизиты-хранилища, чтение происходит в транзакции.
Представляете, насколько это более затратно для СУБД, чем запрос
Выбрать ДокументПоступления.Номер
ИЗ Документы.ПоступлениеТоваровУслуг КАК ДокументПоступления
Где ДокументПоступления.Ссылка = &Ссылка
Поэтому в современных типовых программах разработчики не используют объектное чтение.
но вы ориентируетесь на то, что якобы знаете как работает платформа.
а вы уверены, что разработчики платформы заложили именно такой "затратный по производительности" механизм объектного извлечения данных?
то есть по сути, мне нужен ИНН контрагента, я прописал Контрагент.ИНН. А они заложили в платформе, что тащится весь справочник Контрагентов со всеми табличными частями? Может быть, стоит им написать, чтобы они улучшили свой алгоритм и не извлекали лишнего?
Я проверял в профайлере, всегда работает одинаково.
Разработчики платформы хотели бы что-то изменить,
но их связывает обратная совместимость и прочие обязательства.
при объектном чтении, все таки, возможно, проблема не в том, что тащатся все реквизиты с табличными частями, а скорее в случаях, когда пишут такой код:
НоваяСтрока = ТаблицаКонтрагенты.Добавить();
НоваяСтрока.ИНН = КонтрагентСсылка.ИНН;
НоваяСтрока.КПП = КонтрагентСсылка.КПП;
НоваяСтрока.Наименование = КонтрагентСсылка.Наименование;
В этом случае, вроде как выполняется три запроса, а при использовании функции ОбщегоНазначения.ЗначениеРеквизита() - это можно сделать за одно обращение к БД. Хотя тут, возможно, используется кэш, но это неточно.
и в следующих случаях запросов к СУБД нет. Но это все равно плохо.
Посмотрите ссылку комментария (18).
Добавили бы в конфигуратор для всех реквизитов признак "Вызов через точку" - чтобы не тащить все остальные поля при такой конструкции "Контрагент.ИНН".
(5) Не лучший пример (получение поля "номер"). Основные поля прикладных объектов кэшируются без чтения всего объекта. При их получении через точку весь объект не будет считан. А вот ДокументСсылка.Организация, считает весь объект.
// Занудство OFF
Для меня это не занудство. я сам такой.
Мне это интересно для подготовки к экзамену.
Можете привести ссылку на первоисточник ?
Везде пишут не используйте это не используйте при этом типовые конфы такое вытворяют... что думаешь там рельно ии уже сидит и по тз код строчит
Не соглашусь. Очень удобно, когда новые объекты конфигурации добавляются в конец списка. В таком случае, во-первых ты имеешь представление о том, что делают другие участники команды, во-вторых часто возникает необходимость обратиться к объектам, добавленным пару месяцев назад, тобой или кем-то другим, при этом уже не помнишь или не знаешь точное название этих объектов. В этом случае просто открываешь список документов, бежишь глазами вверх и быстро находишь нужный объект
для конечного продукта и конечного потребителя - лучше отсортировать, и тогда - когда внедренец будет добавлять свои объекты - он будет различать , где типовые (по поставке продукта), а где его.
в вашем случае - при разработке продукта и тем более в команде удобно видеть новые создаваемые объекты, поэтому сортировать не целесообразно.
Сортировка должна происходить между процессом разработки и продажей продукта - получается промежуточным этапом.
мне тоже было непривычно, потом понравилось.
Специально проверил - в типовой все сортировано.
Не соглашусь с "не соглашусь".
При обновлении этот принцип "новые объекты конфигурации добавляются в конец" - херится напрочь. В итоге - в конце списка тупо каша из добавленных кастомных объектов и новых объектов типовых..
Если требуется систематизировать работу с кастомными объектами - лучше их выделять в отдельную подсистему/подсистемы.
Оригинальная подача материала - удобно для восприятия, затратно по времени подготовки.
Как реализовали ?
А сейчас, цену не стоит так извлекать? Что потащится из базы при использовании такой конструкции? вроде как вся запись по отбору регистра сведений....
И хотя для регистров нет однозначного ответа, но на мой взгляд лучше запрос.
Например если на регистр наложен РЛС, объектное чтение набора с запрещенными записями выдает исключение.
А с объектным чтением документа с табличными частями почему то не воспроизвелось, нет и все разделяемой управляемой блокировки. ))
Лично для меня открытием стала книга С. Макконела "Совершенный код".
Некоторые главы как будто специально для 1С написаны.
2.2. Перем НоваяПеременная1, НоваяПеременная2;
//- ПРЕФИКС <Фамилия И.О. разработчика>
Модный нынче Git еще не освоили?
Этот и последующие образцы для комментирования - разве не дурной тон по тому же Макконнеллу? Представьте один типовой модуль, в который раз в месяц один из разработчиков вносит изменения. Этот модуль уже через год-два превратится в зеленую лужайку из-за комментариев, где кое-где встречаются конструкции языка. Такой "зеленый" модуль усложняет чтение самого кода.
И еще зачем использовать "ПРЕФИКС_" в добавлении ко всем объектам, реквизитам, функциям и так далее? Вот никогда не понимал, почему так делают. Мое предположение, что это было крайне важно в 7.7 (я с ней не работал), и программисты старой закалки перетащили это в 8.х, где это не приносит существенной пользы.
Вот если модуль типовой то как раз пусть вносит комментарии, кто, когда и что изменял или дополнял. Если же модуль его собственный то тут уже по ситуации.
ФИО разработчика и когда внесено изменение - это задача системы контроля версий.
есть мнение, что такие комментарии - нелепые и что EDT и GIT вскоре решат эту проблему.
Но пока сам не пробовал. Мы используем именно такие комментарии.
Это помогает при обновлении и поддержке. Возможно, это не эталон.
Используется обычное хранилище, разработчики также работают. Настроен скрипт на OneScript, который при помещении коммита в хранилище, добавляет информацию в git.
На инфостарте уже два года про это статьи пишут.
Спасибо за статью, сам все хочу приобрести эту книгу, но никак руки не доходят. Вы говорите, что она хорошо подходит и для 1С?
Вопросы, замечания по тексту:
1. ЗначениеРеквизитаОбъекта - а разве можно передавать структуру, чтобы получить реквизит реквизита? У вас какая-то доработанная версия?
2. Честно говоря, мне не нравится как 1С выравнивает многострочные логич выражения. Я бы их ставил на уровне первого Если, а не вложенного кода. Я один такой?
3. "аргументы функции (процедуры) при возможности сохранять в структуре значений, которая будет единственным аргументом" - вот что-то никак не могу это принять. Да, для кастомизации это круто, можно спокойно добавлять новый параметр, не переписывая везде интерфейс. Но вот для понимания и читабельности... Что, кому-то это удобнее? Тут становится понятно только по описывающему комментарию перед функцией. Но ведь рядом же написана мысль, что хороший код в комментах не нуждается.
4. "Модули форм оформляются через области, используя стандартные и, при необходимости, свои" - список, что дальше, это официальный, из ИТС? Не встречал его раньше.
P.S. Сама подача материала не очень понравилась. Я не приветствую клиповость, особенно для статей на такую серьезную тему. Лучше текст почитать.
С другой стороны, может вам здесь как раз не хватило этой клиповости. Вы в начале написали, я ждал какой-то яркой картинки, а в итоге не сразу заметил, что картинки вообще меняются. Если уж идти в этом направлении, то должны быть стрелки, другие яркие элементы для привлечения внимания, какая-то динамика.
1. Да, попробуйте сами. У нас версия БСП не новая.
2. Возможно, 1С выравнивает многострочные логич выражения не лучшим способом.
я исходил из девиза "Безобразно, но однообразно"
3. Использовать структуру как аргумент - это тренд производителя. В этом что-то есть.
4. Список областей не входит в стандартные требования. Но применяется часто.
5. По теме много серьезных статей. Хотелось как-то выделиться. Стрелочки наверное добавлю.
Попробовал пример, как у вас, в УТ 11.4, выдало ошибку:
{ОбщийМодуль.ОбщегоНазначения.Модуль(258)}: Поле объекта не обнаружено (Структура)
Возврат Результат[СтрЗаменить(ИмяРеквизита, ".", "")];Зато работает такой способ: ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "Контрагент.ИНН")
// Параметры:
// Ссылка - ЛюбаяСсылка - объект, значения реквизитов которого необходимо получить.
// - Строка - полное имя предопределенного элемента, значения реквизитов которого необходимо получить.
// Реквизиты - Строка - имена реквизитов, перечисленные через запятую, в формате
// требований к свойствам структуры.
// Например, "Код, Наименование, Родитель".
// - Структура, ФиксированнаяСтруктура - в качестве ключа передается
// псевдоним поля для возвращаемой структуры с результатом, а в качестве
// значения (опционально) фактическое имя поля в таблице.
// Если ключ задан, а значение не определено, то имя поля берется из ключа.
// - Массив, ФиксированныйМассив - имена реквизитов в формате требований
// к свойствам структуры.
// ВыбратьРазрешенные - Булево - если Истина, то запрос к объекту выполняется с учетом прав пользователя, и в случае,
// - если есть ограничение на уровне записей, то все реквизиты вернутся
// со значением Неопределено;
// - если нет прав для работы с таблицей, то возникнет исключение.
// - если Ложь, то возникнет исключение при отсутствии прав на таблицу
// или любой из реквизитов.
//
// Возвращаемое значение:
// Структура - содержит имена (ключи) и значения затребованных реквизитов.
// - если в параметр Реквизиты передана пустая строка, то возвращается пустая структура.
// - если в параметр Ссылка передана пустая ссылка, то возвращается структура,
// соответствующая именам реквизитов со значениями Неопределено.
// - если в параметр Ссылка передана ссылка несуществующего объекта (битая ссылка),
// то все реквизиты вернутся со значением Неопределено.
//
Функция ЗначенияРеквизитовОбъекта(Ссылка, Знач Реквизиты, ВыбратьРазрешенные = Ложь) Экспорт
2. Да, в общем, девиз правильный, просто решил поделиться, мнение узнать.
3. В смысле, тренд 1С? А где такое можно посмотреть? Как-то везде пока вижу кучу аргументов.
Недавно обновлял типовую конфигурацию,
видел несколько функций где 1С заменили несколько аргументов на структуру.
Найти ссылку на ИТС про аргументы ?
Про аргументы в заголовке функции:
Правильно сгруппировать параметры, описывающие значения реквизитов номенклатуры, в структуру ЗначенияРеквизитов:
Про список областей - то же самое: есть стандарт на ИТС.
ЗначениеРеквизитаОбъекта - исчерпывающую информацию можно получить прямо из описания метода (в том числе примеры вызова). Сигнатура и способы вызова не менялись очень давно, то есть, описанный пример актуален и для древних конфигураций
В статье нет копипаста с ИТС.
Некоторые разработчики 1С не читали "Совершенный код".
На это и рассчитываю.
В первом пункте некорректно рассчитывается сумма товаров документа.
Во-первых, Вы используете для обхода выборки цикл, тогда как в результате запроса будет всегда ровно одна строка. На мой взгляд, с которым Вы вполне законно можете не согласиться, для получения данных выборки, где может быть не более одной строки корректнее использовать конструкцию "Если", а не "Цикл". Причина та же, что и для правил именования переменных: так мы подсказываем читающему код разработчику, что в результате не может быть более одной строки. Но это дело вкуса.
Во-вторых, возможны ситуации, когда результатом вычисления суммы товаров документа будет NULL. Это случай с пустой табличной частью "Товары". Мне кажется это также неожиданным для дальнейшего использования результатом, и предпочтительнее здесь получить именно 0. На это намекает инициализация переменой суммы и наличие цикла обхода выборки вместо безусловного "Выборка.Следующий()". Но конечно же, что возвращать - NULL или 0, зависит от решаемой задачи.
Так нельзя
IDE должен сам искать ошибки, в языке ява например придумано много доп. компонентов псевдо SQL язык чтоб ошибки выходили в DesignTime а не RunTime
2) Пример 4
Так нельзя.
С новой строки без отсупа должна находиться новая логическая операция а не продолжение прошлой.
3) Пример 5
Так нельзя.
Слово "Тогда" должно находиться с новой строчки если в условии несколько проверок
4) Пример 6
Так нельзя.
"Мягкий" хардкодинг надо делать путём создания функции в общем модуле
5) Пример 7
Так нельзя.
Международный стандарт правильного именования переменных "Венгерская нотация" говорит что перед именем переменной надо писать тип переменной(сокращённо)
например
ТЗНоменклатура
а не НоменклатураПоступления
6) Пример 8
Так нельзя.
Процедуры и функции должны быть "самодокументируемые" чтоб было всё понятно без документации.
Чему только людей учите :(
Где можно "международный стандарт" почитать? На сколько знаю от ВН отказались даже в МС где изначально её и придумали применять.
"...General Naming Conventions Microsoft .NET
- DO NOT use Hungarian notation."
В хороших языках программирования со строгой типизацией венгерская нотация не нужна конечно, там тип переменной итак строго задан, но это не про 1С
Текстовый редактор системы 1С:Предприятие предоставляет функции автоматического форматирования управляющих конструкций встроенного языка.
Помимо автоматического форматирования текста модуля в процессе ввода, можно также отформатировать уже введенный текст. Для этого необходимо выделить блок текста, который требуется отформатировать, и выбрать "Текст - Блок - Форматировать". При этом текстовый редактор проанализирует текст модуля и произведет его форматирование, при котором содержимое каждой синтаксической конструкции будет сдвинуто вправо на величину табуляции независимо от первоначального расположения строк (лидирующих пробелов).
(с) сп
Встроенный инструмент форматирования предназначен для оформления управляющих конструкций встроенного языка и не умеет ни в один из пунктов .
Поэтому аппелирование к нему в данном случае считаю некорректным, а отступы конструктора запросов более каноничными.
в статье речь идет о стандартах 1С, поэтому лучше ссылаться на сайт ИТС, чем на Вики.
Откуда Вы набрали таких категоричных утверждений ?
Можете привести источник ?
В комментариях я несколько раз признал свою неправоту
и перечислил СМ в знак благодарности.
1) Давно Вики стала авторитетным источником учитывая что вносить правки в неё может любой желающий, даже не имеющий опыта работы программистом?
2) В вопросе написания когда под 1С сайт ИТС куда авторитетнее чем Вики.
Использовать Структура и ТаблицаЗначений в наименовании не плохо и не хорошо.
Но в свежем коде производителя это как правило не используется.
Указание типа переменной в языке с динамической типизацией может ввести в заблуждение относительно её типа.
Ничего плохого нет в переменной тзПредварительная, плохо когда начинают весь код писать в таком стиле, придумывают целую систему типов, начинают в название переменной добавлять префиксы означающие простые типы и тд.
Если ( Условие1=Значение1
И Условие2=Значение2
И Условие3=Значение2
)
ИЛИ Проверка1()
ИЛИ Проверка2()
ИЛИ Проверка3()
Тогда
КонецЕсли;
ПоказатьВ общем люблю когда условия выровнены
Аналогично хорошо так же декларировать аргументы функций и вызовы самих функций (когда их больше 3,4, хотя большое число аргументов у функций - тоже считается не очень хорошим тоном - но если они в основном не обязательны и могут быть заданы поименовано при вызове функции - то это даже очень удобно)
функция МояФункция( Аргумент1,
Аргумент2,
Аргумент3=неопределено,
Аргумент4=1)
возврат "Результат";
КонецФункции
рез = МояФункция( Переменная1,
Переменная2.Поле1,
,
6273);
ПоказатьЖаль 1С не поддерживает именованные аргументы - как многие из современных языков программирования - типа вот так:
рез = МояФункция( Переменная1,
Аргумент3:6273,
Аргумент2:Переменная2.Поле1);
Ну а про отсутствие в 1С кортежей - я вообще молчу :-(
Хотя динамические структуры - вещь очень полезная - предпочитаю их для передачи параметров!
1) В том то и дело - что ТОГДА я располагаю на том же уровне что и ЕСЛИ - т.к. с моей точки зрения семантически это конструкции одного уровня выражения - слово ЕСЛИ открывает блок условий - слово ТОГДА - открывает блок основного тел условия - как слово ИНАЧЕ - открывает блок второй ветви тела ветвления. По аналогии с оператором
ПОПЫТКА
//Код тела попытки
ИСКЛЮЧЕНИЕ
//Код тела исключения
//Если бы 1С подерживало был бы и 3-й блок
//ЗАВЕРШЕНИЕ
//Код тела завершения алгоритма при любом исходе попытки
КОНЕЦПОПЫТКИ
аналогично и с циклами
ПОКА
//Условия
ЦИКЛ
//Тело цикла
КОНЕЦЦИКЛА
В современных языках такие конструкции всё чаще могут интерпретироваться как выражения и эти ключевые слова разделяют секции выражений. Секция ТОГДА никак не вложена в секцию ЕСЛИ - и поэтому должна быть на одном уровне с ней.
Но это мой мнение.
2) Ну я так и написал - когда их больше 3,4 - читайте больше четырёх
3) Но всё же гораздо удобнее при числе аргументов больше 4 - это использовать уже именованную префиксацию аргументов при их вызове - т.к. когда их очень много (а 5 и более это уже много) в них очень тяжело ориентироваться как при написании вызова функции, так и при анализе текста.
И особенно это удобно когда большая часть таких аргументов не обязательные (со значениями по умолчанию) и используются то одни то другие в разных местах им в разных сочетаниях - особенно когда ещё и целыми группами используются и не используются
Но, обычно я современных языках программирования применение именной адресации не накладывает условий на дизайн самой функции; не накладывает обязательств всегда вызывать функции именно с именованными аргументами; и можно даже комбинировать вызов (как это у меня показано): когда часть аргументов вызываются не именованно - в порядке их декларации в заголовке функции, а часть именовано - в любом порядке и составе.
Но ещё раз замечу - на мой взгляд при большом числе аргументов - их удобнее передавать уже через динамические структуры (а в статических языках для этого рекомендуют создавать статические структурные типы) - тем более, что 1С EDT поддерживает специальные заголовки комментариев для параметров типа "Структура" что даёт всплывающую подсказку по их составу в IDE - жаль нет пока функции рефакторинга по извлечению создания такой структуры из имени исползованной функции.
Кстати, передача параметров через структуру - это очень удобное решение - когда к функции добавляются новые параметры (не обязательные для всех уже используемых месть вызова функции) - что позволяет не переписывать код (и уж тем более когда они удаляются, или переставляются).
Более того данное решение просто обладает невероятной мощью - когда используется сквозная структура передачи параметров сразу в несколько функций глубокой вложенности - особенно это удобно когда нужно расширить параметры глубоко вложенной функции и передать их где-то ещё сверху, в начальной точке вызова, чтобы не переписывать все вложенные функции среднего уровня вложенности. Это очень здорово помогает при интеграции доработок в конфигурации от других вендоров (не важно - используются расширения конфигураций или нет).
но теперь придумали новый псевдоязык Query DSL
смысл которого только в том что при неправильном написании имени поля(колонки БД) приведёт к ошибке в DesignTime(IDE,конфигуратор) а не в RunTime(у пользователей)
Просто 1С отстаёт лет на 5-10 от нормальных языков программирования.
Надёжность программы намного важнее чем скорость !
А вообще - будущее за декларативными языками описания бизнес логики - где написанные команды будут восприниматься как требования и намерения к достижению результата, а интерпретатор ещё на стадии конфигурирования будет их перекладывать на оптимальные внутренние инструкции к runtime-процессору (каким бы он ни был - оптимально сейчас - это LLVM-машина или Java runtime-машина, но можно и сразу в инструкции ЦПУ компилировать - хотя это плохая идея, уж лучше сначала в LLVM-код а уже на стадии выполнения делать JIT-компиляцию), с оптимизацией и распараллеливанием выполнения, при необходимости.
Код мы читаем раз в сто больше, чем пишем. Порой приходится для одной строки прочитать целый фолиант. А это все ВРЕМЯ, а значит ДЕНЬГИ. А зачем все это надо можно почитать вбив в Гугле "чистый код". Наверное не зря признанные метры программирования столько пишут об этом. Огорчает, что низкий порог вхождения в профессию программист 1С тянет за собой тонны кода, с которым потом бизнесу приходится жить и оплачивать потраченное программистами время.
Тем более, что в БСП это тоже делается одной строчкой, хоть и более длинной. А если конфа без БСП, стоит подумать хотя бы о переносе модуля ОбщегоНазначения. Там вообще много хороших функций.
- не читайте литературы;
- исключите ревью кода.
- тестируйте на своей файловой базе с двумя-тремя объектами.
По моему опыту это примерно так происходит.
ОбщегоНазначения тянет за собой ОбщегоНазначенияПовтИсп, ОбщегоНазначенияКлиентСерверный, а они в свою очередь кучу других. Это ещё полбеды, главное, мало кто изучает эти модули. Проще набыдлокодить.
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Как по мне, код нужно писать на идеально, а оптимально. Для разных задач может использоваться разный подход написания.
И да, не нужно слепо следовать стандартам 1С.
Эти оптимизации помогают на приличных базах сократить сотни секунд серверных вызовов. Вы недооцениваете эти рекомендации.
...бывают проекты, когда по приоритетам внедрить как
Я не очень понимаю, почему вы считаете, что тут дело в стандартах кода. Не использовать запрос в цикле при печати массива документов это не стандарт кода, это элементарно квалификация, во всех типовых так применяется. Да и код не усложняется, по крайней мере, если написал так хотя бы два три раза. Писать ПолучитьЗначениеРеквизита не вопрос стандарта, это вопрос того, как будет ваше приложение медленно работать.
Да, некоторые не знают, что запрос в цикле нужно избегать, но это не вопрос к их стандартам, это вопрос к квалификации. Кто хоть раз делал замеры по производительности, на любой базе, тот всегда будет писать один запрос для всех объектов.
(146)
при внедрениях я порой не слежу за стандартами, и могу запросто использовать запрос в цикле для разовой обработки данных.
Запрос в цикле - это плохо, я знаю. Но в моем случае скорость разработки намного важнее, чем скорость обработки данных.
давайте закроем тему.
1. Для подобного рода синтаксического контроля есть SonarQube (возможно есть еще что-то...), причем правил по написанию кода не 3 а, 233. Вплоть до отчетов по качеству когда и созданного технологического долга.
Выискивать код который написан "Не стандартно", по всей конфигурации, самостоятельно, сверяясь со всеми "стандартами" о которых было миллион раз написано на инфостарте, методолгами на сайте 1С и т.д не рационально и ОЧЕНЬ спорно и трудозатратно.
2. Дело не в "клиповом" мышлении, а дело в том, что 1 содержательная картинка, лучше чем 100 (или больше) слов. Именно по этому бизнес аналитики пользуются различными нотациями при описании бизнес-процессов, по этому инструкции для пользователей нарезаются из скриншотов, именно по этому вы подключаетесь к клиенту по удаленному доступу и смотрите в его экран, это удобно и информативнее. Именно по этому я дочитал эту статью до конца.
3. Тема с разыменованием полей не до конца раскрыта.
3.1 Когда вы пишете запрос следующего вида:
|ВЫБРАТЬ
|СУММА(Документ.Ссылка.ЕщеЧтоТо.Контрагент.ИНН) КАК Сумма
т.е. где больше одного разыменования поля, следует все таблицы дополнительные присоединять через левое соединение. "ЕщеЧтоТо" должно быть отдельным левым соединением. В противном случае весь смысл использования запроса теряется.
3.2 Например получилась такая ситуация и я вынужден использовать "НайтиПоКоду"
КодВалютыРубля = "000000001";
Рубль = Справочники.Валюты.НайтиПоКоду(КодВалютыРубля);
При таком написании не важно где вы используете этот стандарт например:
HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере);
... получаем код возврата
НеверныйЗапрос = 400; //HTTP 400 Bad Request
Если Результат.КодСостояния = НеверныйЗапрос Тогда
//что-то делаем
КонецЕсли;
И вот это правильно.
Подведя черту хочу сказать следующее:
Возможности платформы, которые доступны разработчикам "из коробки", в области автоматизированной проверки качества кода, автоматизированного тестирования, версионирования кода и .т.п убогие и требуют серьезных трудозатрат по автоматизации этого процесса.
Можно написать миллион статей и комментариев про то "как надо" и это не будет выполняться в следствии понятных всем причин. Как минимум можно все эти "надо" оспорить в одностороннем порядке и не делать, просто потому что я считаю что вы не правы, кто-то не прочитает статью, кто-то забудет, не заметит, пропустит, отвлечется в момент того когда надо будет проконтролировать качество написания когда и все, создан технологический долг, который
p.s. пока пиал комментарий, попытался перейти на ИТС и прочитать , на что мне вернулась ошибка 404. В моем случае я даже не смог его прочитать, а не просто забыл использовать его в работе :)
Можно писать код по стандартам сразу.
Так про то и речь. Сонары это прекрасно, но это сторонний и платный продукт. Конфигурировать придерживаясь стандартов это относительно бесплатно.
Да "сразу" ничего не бывает. Инструкцию обычно читают или когда не получается или когда сломал.
В него же можно загружать через generic issue результаты статанализа EDT и АПК тоже все открыто и бесплатно.
Это спорная рекомендация. Строка есть строка, убирать отступ из текста запроса эквивалентно такой записи:
ИмяПеременной =
"https://its.1c.ru/db/content/v8std/src/200/200/i8100655.htm?_=1557240531";
Что не кажется правильным...
* Что делать с частью выражения, переносимой на следующую строку
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Первая строка из этой цитаты - рекомендация, утверждение, ошибка форматирования?
Вторая строка запрещает делать так?
// Неправильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
// Правильно?
Переменная = Новый Структура;
ПеременнаПодлиннее = Новый ТаблицаЗначений;
СовсемДлиннаяПеременная = Новый Запрос;
ПоказатьБез выравнивания правых значений код становится трудно читаемым и противоречит рекомендациям 1С - .
Здравствуйте !
* Не выравнивайте правые части выражений присваивания (Как видите, актуально)
* Размещение каждого оператора на отдельной строке
Это тезисы из "Совершенный код". Первая строка - открытый вопрос, вторая - рекомендация. На сайте ИТС написано "допускается", а не "рекомендуется". На мой взгляд, это свидетельствует, что выравнивание вправо не является предпочитаемым методом.
Уже 3 года работаю с конфигурацией ERP и постоянно вижу, что такое выравнивание употребляется довольно часто. Вот из БСП.
1) Придирка. Утверждать что объектное чтение медленнее, поскольку вместе с нужным реквизитом тянется весь объект (если не учитывать кэш), а запрос читает только то что заказали немного некорректно. СУБД оперирует страницами. Для нашего любимого MS SQL по умолчанию 8 кб. При выполнении запроса на чтение скуль прочитает в память минимум 1 страницу. Что (скорее всего) с запасом перекроет разницу. Поэтому объявлять крестовый поход против объектного чтения все же не стоит. Код усложнится, а будет ли заметная выгода еще не факт.
2) Не отмечено важное отличие 2 техник. Возможность читать запросом только РАЗРЕШЕННЫЕ данные. Есть ли на сайте люди, не наступившие ни разу на эти грабли? Когда разрабатываем - все хорошо, передаем изменения бесправным юзерам - пошли баги.
Так и в первом и во втором случае SQL прочитает страницу. Объектный режим чтения это тот же запрос к БД.
Только в случае объектной модели платформа прочитает весь объект, создаст его структуру и тд. При чтении запросом мы получим только значение указанных нами реквизитов.
Или нет?
Так обсуждается не конкретный пример, а подход в целом.
И сколько страниц будет прочитано SQL сервером при объектной модели если объект будет содержать несколько табличных частей?
А нам например нужны только значения реквизитов документа.
Так можно сразу писать "не через точку", без всякого фанатизма, тогда ничего искоренять и исправлять не придётся и можно спокойно заниматься оптимизацией и профилированием "горячего" кода.
Конечно лучше. Еще лучше сразу писать код не нуждающийся в тестировании и отладке. Недавно тут пробегал такой материал, как правильно прогов нанимать, там такое проповедовалось. Жаль что не всегда получается.
очень даже выйдет
ВремяНачала = ТекущаяДата();
СтрокаРезультата = мРезультатЗапроса.Выбрать();
Пока СтрокаРезультата.Следующий() Цикл
Сообщить(СтрокаРезультата.Контрагент.Инн);
//Сообщить(ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СтрокаРезультата.Контрагент, "ИНН"));
КонецЦикла;
ВремяВыполнения = ТекущаяДата() - ВремяНачала;
Сообщить(ВремяВыполнения);
Показать3500 строк в выборке
36 секунд в первом варианте и 27 во втором.
Справочник "Контрагенты", как Вы изволили выразиться - "небольшой объект"
на разовой разницы нет, это да. Но ты пишешь процедуру-функцию, в ней вот такой код. Завтра твоя процедура очень кому-то понравится и он будет ее в цикле гонять... Поэтому лучше сразу писать через БСП-шные функции. Рисков меньше
90 процентов всех "ускорений" решается убиранием объектного чтения
А за такое надо бить по рукам не зависимо от стиля чтения в процедуре. Запрос в цикле это бяка в любом случае. Даже БСП-шный.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1070752
Создание 03.06.19 09:00
Обновление 04.11.20 11:40
Просмотры 16796
Загрузки 0
Рейтинг
71
Комментарии 150
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
