Перейти к основному содержимому
Версия: 7.0

Правила lsFusion

СИСТЕМНЫЙ ПРОМПТ — ПРАВИЛА ЗАДАЧ lsFusion

ОБЛАСТЬ: lsFusion

Этот набор правил применяется ко ВСЕМ задачам, связанным с lsFusion (включая анализ, how-to, примеры, поиск документации, исследование проекта и написание кода).

Этим правилам НЕОБХОДИМО следовать.​

ОБЯЗАТЕЛЬНЫЙ ПОРЯДОК РАБОТЫ

  1. ПОРЯДОК ИДЕНТИФИКАЦИИ ЭЛЕМЕНТОВ (ОБЯЗАТЕЛЬНО) Ассистент ОБЯЗАН рассуждать об элементах lsFusion строго в следующем порядке:

    1. типы элементов, модули, классы
    2. свойства
    3. действия
    4. формы
    5. прочие элементы

    Ассистент НЕ ДОЛЖЕН переходить сразу к действиям или формам до прояснения контекста модуля / класса / свойства.

  2. ИСПОЛЬЗОВАНИЕ ИНСТРУМЕНТОВ (ОБЯЗАТЕЛЬНО) Для задач lsFusion ассистент ОБЯЗАН активно использовать ВСЕ следующие категории:

    • how-to-руководства / примеры / аналогии
    • поиск документации
    • структурный поиск элементов в проекте

  3. ПРАВИЛО IDE / ВАЛИДАЦИИ (ОБЯЗАТЕЛЬНО) Если доступны диагностика IDE или проверка ошибок, ассистент ОБЯЗАН их использовать.

    Чистая проверка синтаксиса допустима только как запасной вариант, когда диагностика IDE или проверка выполнением недоступны.

ПРАВИЛА ИСПОЛЬЗОВАНИЯ ИНСТРУМЕНТОВ lsFusion

ОБЩАЯ ОБЛАСТЬ ЗАПРОСОВ

  1. При обращении к инструментам lsFusion ассистент ОБЯЗАН задавать только абстрактные или технические вопросы, такие как синтаксис, семантика, поведение платформы, паттерны, примеры, ограничения или поиск элементов.

  2. Ассистент НЕ ДОЛЖЕН спрашивать у инструментов lsFusion про конкретную бизнес-логику, бизнес-правила, доменные смыслы или проектные бизнес-решения.

  3. Конкретная бизнес-логика текущего проекта ДОЛЖНА выводиться из репозитория, от пользователя и из явного контекста проекта, а не из запросов к инструментам lsFusion.

A. HOW-TO И ПРИМЕРЫ

  1. Для любой связанной с кодом задачи lsFusion ассистент ОБЯЗАН сначала извлечь how-to или примеры.

  2. Ассистент ОБЯЗАН декомпозировать задачу на мелкие подзадачи, каждая из которых порождает небольшой объём кода.

  3. Ассистенту СЛЕДУЕТ предпочитать рассуждение в стиле how-to спекулятивным крупным переписываниям.

  4. Ассистенту СЛЕДУЕТ переиспользовать паттерны платформы из примеров прежде чем изобретать собственную структуру.

B. ПОИСК ДОКУМЕНТАЦИИ

  1. Прежде чем запрашивать документацию, ассистент ОБЯЗАН сначала определить текущие типы элементов.

  2. Ассистент ОБЯЗАН извлечь определения и синтаксис для этих типов элементов до редактирования.

  3. Если синтаксис, поведение или возможность неясны, ассистент ОБЯЗАН обратиться к документации прежде чем продолжать.

  4. Извлечение из сообщества СЛЕДУЕТ использовать только когда документации и how-to недостаточно для глубокой или неоднозначной задачи.

C. ПОИСК ЭЛЕМЕНТОВ

  1. Ассистенту СЛЕДУЕТ предпочитать структурный поиск элементов обычному текстовому поиску.

  2. Перед поиском ассистент ОБЯЗАН определить нужные типы элементов, модули и классы.

  3. Ассистент ОБЯЗАН попытаться найти требуемые элементы одним вызовом структурного поиска с правильными фильтрами.

  4. Если цель найти не удаётся, ассистент ОБЯЗАН выполнить хотя бы один запасной шаг:

    • поиск с минимальными фильтрами для получения обзора проекта
    • поиск связанных элементов от уже найденных

  5. Ассистенту СЛЕДУЕТ предпочитать поиск по ключевым словам регулярным выражениям, когда это возможно.

  6. Ассистент ОБЯЗАН оценивать и осознанно задавать размер вывода и таймаут исходя из сложности задачи.

ПРАВИЛА СИНТАКСИСА

  1. Используйте одиночное = как оператор равенства по умолчанию в генерируемом коде lsFusion.

    == — корректный синтаксис, но он НЕ ДОЛЖЕН быть стилем по умолчанию, кроме случаев сохранения существующего кода или соответствия явному запросу пользователя.

  2. Свойства и формы ДОЛЖНЫ быть объявлены до использования. Ассистент НЕ ДОЛЖЕН полагаться на использование вперёд.

ПРАВИЛА ТИПА BOOLEAN

  1. Ассистент ОБЯЗАН использовать FALSE только для TBOOLEAN.

  2. Для BOOLEAN единственные значения — TRUE и NULL.

  3. Для BOOLEAN значение NULL ДОЛЖНО трактоваться как значение по умолчанию.

ПРАВИЛА СВОЙСТВ

  1. Ассистент НЕ ДОЛЖЕН объявлять свойство, если оно используется только один раз.

    Исключение: свойство всё же можно объявить, если оно добавляется на форму.

  2. Каждый параметр свойства ДОЛЖЕН использоваться в его выражении. Неиспользуемые параметры запрещены.

  3. Ассистент ОБЯЗАН предполагать стандартное распространение NULL для выражений свойств: если любой параметр равен NULL, результат равен NULL.

  4. Ассистент НЕ ДОЛЖЕН использовать GROUP AGGR внутри произвольных выражений.

    GROUP AGGR допустим только в определениях свойств.

    Рассуждая о нём, ассистент ОБЯЗАН трактовать GROUP AGGR как GROUP MAX с дополнительным ограничением.

  5. Ассистенту СЛЕДУЕТ избегать лишних условий, когда семантика языка уже даёт требуемый результат.

  6. Ассистент НЕ ДОЛЖЕН создавать свойство, выражение которого равно одному из его параметров.

  7. Ассистент НЕ ДОЛЖЕН создавать несколько свойств с идентичными выражениями.

  8. Если свойство вычисляется из другого свойства, но имеет другие параметры, ассистенту СЛЕДУЕТ постараться сохранить то же имя свойства.

  9. Чтобы проверить, что свойство равно NULL, ассистенту СЛЕДУЕТ использовать IF NOT property(...).

    Чтобы проверить, что оно не NULL, ассистенту СЛЕДУЕТ использовать IF property(...).

  10. Ассистенту СЛЕДУЕТ указывать CHARWIDTH в определении свойства, а не в дизайне формы.

Для простой композиции свойства, которая лишь пробрасывает другое свойство, ассистенту НЕ СЛЕДУЕТ повторять CHARWIDTH на производном свойстве, если оно не должно отличаться.

  1. Для статических объектов ассистент НЕ ДОЛЖЕН использовать свойства staticCaption или staticName.

    Вместо них ассистент ОБЯЗАН использовать caption и name.

  2. Имена свойств СЛЕДУЕТ делать краткими и избегать лишних слов.

  3. Ассистенту НЕ СЛЕДУЕТ использовать в имени свойства слова, дублирующие имена классов параметров, кроме случаев, когда это нужно для ясности.

  4. Ассистенту НЕ СЛЕДУЕТ указывать явное пространство имён для свойства без необходимости.

ПОЛИТИКА ИМЕНОВАНИЯ СВОЙСТВ

  1. Имена свойств ДОЛЖНЫ следовать lowerCamelCase, как в официальных соглашениях кодирования lsFusion: первое слово начинается со строчной буквы, а каждое последующее — с заглавной.

  2. Для собственных примитивных атрибутов объекта ассистент ОБЯЗАН предпочитать кратчайшее устойчивое бизнес-имя, уже используемое в проекте.

    Типичные базовые имена в исходниках: id, name, fullName, number, date, dateTime, status, type, note, details, price, quantity, amount, email, phone, address, city, state, zip, index, count, color, readonly, archived.

  3. Ассистент ОБЯЗАН переиспользовать существующее базовое имя свойства для одного и того же понятия в разных классах и сигнатурах вместо изобретения синонимов.

  4. Ассистенту НЕ СЛЕДУЕТ включать имя класса-владельца в собственный базовый атрибут свойства, когда достаточно обобщённого имени.

    Предпочитайте: name(Partner), email(Partner), number(Order).

    Избегайте: partnerName, partnerEmail, orderNumber.

  5. Ассистент НЕ ДОЛЖЕН добавлять глаголы вроде get, set, calc или compute, а также слова-заполнители вроде value, data, info, в имя свойства, если они не являются частью фактического бизнес-смысла.

  6. Человекочитаемая формулировка относится к заголовку (caption), а не к идентификатору.

    Ассистенту СЛЕДУЕТ держать имя свойства техничным и переиспользуемым, даже если заголовок длинный, локализован или содержит бизнес-формулировку.

ПРАВИЛА ИНТЕРНАЦИОНАЛИЗАЦИИ И ОБРАТНОГО ПЕРЕВОДА

  1. Ассистент ОБЯЗАН использовать файлы *ResourceBundle.properties для локализации UI.

    Значение внутри {...} ДОЛЖНО трактоваться как ключ поиска, который lsFusion разрешает согласно текущей локали.

  2. Ассистент ОБЯЗАН сначала определить, используется ли обратный перевод в текущей области проекта.

    Если используется, ассистент ОБЯЗАН продолжать его использовать в этой области и ОБЯЗАН следовать существующей политике проекта.

    Ассистент ОБЯЗАН сохранять выбор идентификаторов согласованным с уже установленным там паттерном.

    Ассистент НЕ ДОЛЖЕН вводить новую явную политику идентификаторов, если этого не просит пользователь.

  3. Обратный перевод означает перевод в направлении, обратном обычной локализации UI: не ключ -> локализованный текст, а локализованный текст -> ключ, и затем, при необходимости, в другую локаль.

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

ПРАВИЛА ФОРМ

  1. Чтобы разместить несколько объектов в одной таблице сразу, ассистенту СЛЕДУЕТ объединить их в одну группу объектов с помощью скобок.

  2. В секции FORM ... ORDERS ассистент ОБЯЗАН использовать только свойства формы, уже добавленные на форму через блок PROPERTIES.

    В ORDERS ассистент ОБЯЗАН указывать одно из:

    • имя свойства формы с его параметрами, если явный алиас не задан
    • явный алиас свойства формы, если такой алиас был указан

    Сырые выражения, объекты или свойства, не добавленные на форму, НЕ ДОЛЖНЫ помещаться в ORDERS.

  3. Ассистент НЕ ДОЛЖЕН использовать INPUT внутри действий, добавленных непосредственно на форму через PROPERTIES, если это действие не используется в обработчике ON CHANGE.

    INPUT допустим только в обработчиках изменения свойств формы.

  4. Ассистент НЕ ДОЛЖЕН выводить внутренние идентификаторы объектов на форму.

    Вместо них ДОЛЖНЫ показываться осмысленные свойства.

  5. Ассистент НЕ ДОЛЖЕН добавлять на формы свойства, значениями которых являются объекты.

    Вместо них ДОЛЖНЫ выводиться примитивные или производные примитивные / текстовые свойства.

  6. Объект PANEL пользовательского класса по умолчанию НЕ выбирается пользователем.

    Если такой объект должен выбираться пользователем (например, параметр фильтра, показанный на форме), ассистент ОБЯЗАН пометить отображаемое свойство этого объекта как SELECTOR в блоке PROPERTIES.

    Без SELECTOR ячейка панели не открывает диалог выбора, и объект нельзя изменить. Ассистент НЕ ДОЛЖЕН предполагать, что ячейка панели редактируема по аналогии с редактированием в таблице.

  7. Ассистенту СЛЕДУЕТ задавать DESIGN для всех интерактивных форм, содержащих более четырёх свойств.

  8. Исключение: для тривиальной формы с одним-двумя объектами в режиме GRID и без других свойств, показанных в режиме PANEL, опускание DESIGN допустимо.

  9. В DESIGN ассистенту СЛЕДУЕТ предпочитать перемещение контейнеров BOX(...) для таблиц в первую очередь.

    GRID(...) СЛЕДУЕТ использовать только при крайней необходимости.

  10. По возможности ассистенту СЛЕДУЕТ избегать дизайнов форм с более чем двумя таблицами по вертикали и более чем двумя таблицами по горизонтали.

  11. В блоке PROPERTIES формы стиль параметров у свойства или действия, добавляемого на форму, ДОЛЖЕН соответствовать заголовку блока:

    • С заголовком с общими параметрами PROPERTIES(p1, ..., pN) каждая запись ДОЛЖНА указываться только своим идентификатором — общие параметры связываются неявно. Запись propName(p1, ..., pN) после идентификатора — это ошибка разбора.
    • Без заголовка с общими параметрами (просто PROPERTIES) каждая запись ДОЛЖНА нести явные параметры в скобках, например propName(t) или actionName() для действий без параметров.

    Ассистент НЕ ДОЛЖЕН смешивать два стиля в одном блоке и НЕ ДОЛЖЕН повторять общие параметры после имени свойства, когда используется заголовок с общими параметрами.

    Это правило применяется только к записи, добавляемой на форму. Списки аргументов внутри опций вроде ON CHANGE actionName(...), READONLYIF expr, BACKGROUND expr и т. д. — это обычные вызовы действий / выражения и ВСЕГДА используют явные параметры, независимо от заголовка блока.

ПРАВИЛА ПРОЕКТИРОВАНИЯ МОДУЛЕЙ

  1. Ассистент ОБЯЗАН разбивать код lsFusion на модули по доменной логике или функциональной области, а не по произвольной технической группировке.

  2. Ассистенту СЛЕДУЕТ предпочитать относительно короткие модули.

    Один широкий модуль НЕ ДОЛЖЕН продолжать расти, когда логика естественно разделяется на более мелкие связные модули.

  3. Ассистент ОБЯЗАН применять низкую связанность и высокую связность: тесно связанные классы, свойства, действия и формы СЛЕДУЕТ держать вместе, а межмодульные зависимости СЛЕДУЕТ держать узкими и явными.

  4. NAMESPACE модуля СЛЕДУЕТ выбирать по общему бизнес-домену, а не по полному имени модуля.

  5. Когда модуль относится к существующему семейству доменов, ассистенту СЛЕДУЕТ переиспользовать пространство имён этого семейства для всех его элементов.

    Новое пространство имён СЛЕДУЕТ создавать только для действительно нового домена, а не для каждого технического подмодуля.

  6. Если имя модуля уже совпадает с предполагаемым пространством имён домена, опускание NAMESPACE допустимо, поскольку lsFusion использует имя модуля по умолчанию.

    Иначе ассистенту СЛЕДУЕТ указывать NAMESPACE явно.

  7. Ассистенту СЛЕДУЕТ использовать REQUIRE, EXTEND, абстрактные свойства / действия и расширения форм для связывания модулей вместо дублирования логики или создания god-модуля.

  8. Прежде чем добавлять код в существующий модуль, ассистент ОБЯЗАН проверить, относится ли логика к домену этого модуля.

    Если нет, ассистенту СЛЕДУЕТ создать или расширить более подходящий модуль.

  9. Вводя новый модуль, ассистент ОБЯЗАН осознанно выбирать зависимости и избегать циклических или ненужных зависимостей.

ПРАВИЛА ДЕЙСТВИЙ

  1. Ассистент ОБЯЗАН избегать FOR, когда тот же результат можно выразить множественной (set-based) конструкцией.

    FOR итерирует строку за строкой и ДОЛЖЕН быть последним средством, когда нет декларативной альтернативы.

    Предпочитайте множественные альтернативы, например:

    • агрегация или материализация множества -> GROUP SUM, GROUP CONCAT, GROUP MAX, GROUP LAST, GROUP AGGR
    • присваивание свойства по множеству -> прямое присваивание свойства с параметрами вместо цикла FOR ... DO
    • экспорт табличных или иерархических данных -> EXPORT FROM, EXPORT JSON FROM, EXPORT XML FROM, EXPORT CSV FROM
    • построение структурированных данных -> JSON FROM, XML FROM
    • массовые интеграционные записи -> NEW, DELETE или множественное изменение свойства вместо построчного FOR

    FOR приемлем, когда тело имеет настоящий построчный поток управления, такой как условный APPLY, MESSAGE, throwException или внешние вызовы, которые нельзя выразить как операцию над множеством.

ПРАВИЛА СЕССИЙ ИЗМЕНЕНИЙ (NEWSESSION, NESTEDSESSION, APPLY)

  1. Прежде чем вводить NEWSESSION, ассистент ОБЯЗАН решить, какое поведение сессии требуется:

    • изолированная независимая единица -> NEWSESSION
    • изолированная единица, которая также должна видеть отдельные локальные свойства верхней сессии -> NEWSESSION NESTED (...)
    • изолированная единица, которая должна видеть все локальные свойства верхней сессии -> NEWSESSION NESTED LOCAL
    • дочерний диалог или редактор, который должен работать с несохранёнными объектами верхней сессии и возвращать свои изменения в эту верхнюю сессию -> NESTEDSESSION

  2. Для действий, добавленных на формы, есть два основных паттерна:

    • паттерн readonly-формы: форма фактически только для просмотра, поэтому добавленные на неё действия СЛЕДУЕТ по умолчанию выполнять в новой сессии
    • паттерн редактируемой формы: форма имеет редактируемые свойства, поэтому любое добавленное на неё действие, использующее NEWSESSION, ДОЛЖНО либо: APPLY; IF canceled() THEN RETURN; перед NEWSESSION, либо быть полностью независимым от несохранённых изменений в этой форме

  3. Простой NEWSESSION — вариант по умолчанию для изолированной работы, которая не должна случайно применить ожидающие изменения формы вызывающей стороны.

    Типичные паттерны в исходниках:

    • readonly-списочные формы с PROPERTIES(...) NEWSESSION NEW, EDIT, DELETE
    • смена статусов или создание зависимых документов после предшествующего APPLY
    • внешние или интеграционные действия, изолирующие HTTP-вызовы и сохраняющие собственные результаты
    • небольшие немедленные обновления UI с NEWSESSION { APPLY { ... } }

  4. Если внутренняя логика зависит от локального состояния верхней сессии, такого как выделения, отметки или буферы импорта, ассистент ОБЯЗАН явно перенести это состояние через NESTED (...) или NESTED LOCAL.

  5. При использовании NEWSESSION NESTED (...) или NEWSESSION NESTED LOCAL ассистенту СЛЕДУЕТ сохранять те же вложенные локальные свойства на APPLY, если результат должен быть скопирован обратно в верхнюю сессию, например через APPLY NESTED (...) или APPLY NESTED LOCAL.

  6. Ассистент НЕ ДОЛЖЕН заменять NESTEDSESSION простым NEWSESSION для дочерних форм или диалогов, привязанных к родительскому объекту, который может быть ещё не сохранён в текущей сессии формы.

  7. Прежде чем открывать свежую NEWSESSION из действия, запущенного на форме редактирования, ассистенту СЛЕДУЕТ решить, нужно ли сначала сохранить текущие изменения формы.

    Распространённый паттерн: APPLY; IF canceled() THEN RETURN; NEWSESSION { ... }

    Этот паттерн используется перед сменой статусов, генерацией документов и другими изолированными последующими действиями.

  8. После APPLY, если последующая логика зависит от того, удалось ли сохранение, ассистент ОБЯЗАН проверить canceled(). Если неудачу нужно донести до пользователя или интеграции, ассистенту СЛЕДУЕТ использовать applyMessage().

    Если APPLY не проходит из-за ограничения, изменения остаются несохранёнными в текущей сессии, и любой последующий APPLY в той же сессии также не пройдёт, пока проблемные данные не исправлены или изменения не отменены (например, через CANCEL).

  9. Ассистенту СЛЕДУЕТ держать блоки NEWSESSION небольшими и целевыми: изолировать одну единицу работы, применить её при необходимости и выйти.

    Ассистент НЕ ДОЛЖЕН вводить NEWSESSION лишь для сокрытия багов видимости сессии. Если изменения верхней сессии должны оставаться видимыми, требуется семантика вложенной сессии.

ПРАВИЛА ИМПОРТА (IMPORT)

  1. Прежде чем работать с IMPORT, ассистент ОБЯЗАН определить элементы в следующем порядке:

    • модуль и пространство имён, владеющие потоком импорта
    • целевые классы, которые будут создаваться или обновляться
    • промежуточные (staging) свойства, используемые при импорте
    • действия импорта
    • формы импорта, если данные иерархичны

  2. Ассистент ОБЯЗАН осознанно выбирать стиль импорта:

    • плоские файлы (CSV, XLS, DBF, TABLE) -> предпочесть IMPORT ... TO или FIELDS
    • вложенные JSON / XML, структуры родитель-потомок, пространства имён или сопоставление EXTID -> предпочесть импорт через форму
    • построчные интеграционные ответы -> предпочесть FIELDS ... DO

  3. Для плоских импортов, требующих валидации, дедупликации, многопроходной обработки или постобработки, ассистенту СЛЕДУЕТ сначала складывать данные в LOCAL-свойства, обычно по INTEGER-строке, а затем обрабатывать их отдельным проходом FOR imported(INTEGER i).

  4. Ассистенту СЛЕДУЕТ использовать FIELDS ... DO, когда импортируемые значения используются лишь однажды и введение переиспользуемых локальных свойств добавило бы шум.

  5. Ассистенту СЛЕДУЕТ указывать сопоставление колонок явно, когда внешний шаблон фиксирован или разрежен.

    Последовательное сопоставление без явных идентификаторов колонок допустимо только когда сам порядок колонок является согласованным интерфейсом.

  6. Для импорта через форму ассистент ОБЯЗАН объявить выделенную форму импорта до использования.

    Форма ОБЯЗАНА использовать один объект на группу объектов с числовыми или конкретными пользовательскими классами.

    Форме СЛЕДУЕТ отражать внешнюю структуру через:

    • FILTERS для связей родитель-потомок
    • EXTID, FORMEXTID, группы и ATTR только там, где этого требует внешняя схема

    Ассистент ОБЯЗАН помнить, что импорт в форму отменяет ожидающие изменения импортируемых свойств формы в текущей сессии.

  7. Ассистент ОБЯЗАН явно выбирать опции формата, когда от них зависит внешний контракт:

    • HEADER / NOHEADER
    • SHEET
    • CHARSET

    Ассистенту СЛЕДУЕТ предпочитать HEADER для стабильных шаблонов CSV / XLS, потому что NOHEADER может незаметно сопоставить отсутствующие или неверно типизированные колонки в NULL.

  8. Ассистент ОБЯЗАН валидировать ссылочные бизнес-ключи до создания или обновления постоянных объектов.

    Типичные ключи в этом проекте — id, number, коды партнёров или товаров и внешние ссылки.

    Каждая ссылка ДОЛЖНА проверяться в отдельном FOR через GROUP SUM 1 BY по импортируемым значениям ключей.

    По возможности ассистенту НЕ СЛЕДУЕТ записывать разрешённые ссылки в отдельный LOCAL до основной логики импорта.

    Отсутствующие мастер-данные или некорректные данные ДОЛЖНЫ останавливать импорт или выдавать понятную ошибку.

  9. Ассистенту СЛЕДУЕТ разделять сырой импорт и доменное разрешение:

    • сначала разобрать файл или данные в локальные свойства или форму импорта
    • затем проверить ссылки, такие как товар, партнёр, статус, тип или другие справочники
    • только потом создавать или обновлять доменные объекты

  10. Для запускаемых пользователем пакетных импортов и внешних интеграций ассистенту СЛЕДУЕТ изолировать сохранение в NEWSESSION.

    После доменных записей ассистенту СЛЕДУЕТ выполнить APPLY;. Если последующая логика зависит от успеха, ассистент ОБЯЗАН проверить canceled() и выдать applyMessage() или throwException(...).

    Если импорт должен видеть локальные буферы верхней сессии, ассистент ОБЯЗАН использовать семантику вложенной сессии вместо простого NEWSESSION.

  11. Ассистент НЕ ДОЛЖЕН частично сохранять неудавшийся импорт молча.

    Ему СЛЕДУЕТ использовать MESSAGE, RETURN, throwException или явный флаг неудачи, согласованно с вызывающей стороной:

    • интерактивный импорт -> MESSAGE
    • API или фоновая интеграция -> исключение или явное состояние неудачи

  12. При импорте булевых значений ассистент ОБЯЗАН помнить правила булевых типов:

    • BOOLEAN использует TRUE и NULL
    • FALSE корректен только для TBOOLEAN

  13. Для импортов-синхронизаций «создать-или-обновить» ассистент ОБЯЗАН разделять создание объектов и обновление свойств.

    Ассистент ОБЯЗАН использовать один отдельный FOR только для создания недостающих объектов.

    Если импортируемые значения ключей могут быть неуникальны, проход создания СЛЕДУЕТ итерировать по сгруппированным ключам через GROUP SUM ... BY, а не по сырым импортируемым строкам.

    Затем ассистент ОБЯЗАН использовать второй отдельный FOR для обновления свойств найденных объектов.

    Ассистент НЕ ДОЛЖЕН смешивать создание объектов и обновление свойств в одном цикле для импортов-синхронизаций.

    Если требуется полная синхронизация, ассистенту СЛЕДУЕТ добавить явный шаг удаления.

  14. Если LOCAL-свойства промежуточного хранения используются только в одном действии импорта, ассистент ОБЯЗАН объявлять их внутри этого действия.

    Ассистенту НЕ СЛЕДУЕТ выносить такие LOCAL-свойства на уровень модуля без необходимости.

    Исключение: LOCAL-свойство можно объявить вне действия только когда оно должно использоваться формой импорта или переиспользоваться несколькими связанными действиями.