Структура модуля

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

🟡Разделы оформляйте областями и не оставляйте пустых.

🟡Публичный интерфейс — сверху, чтобы его было видно первым.

🟡Обработчики событий располагайте выше служебных методов и группируйте по элементам формы.

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

🟡Используйте заготовленные шаблоны оформления модулей

#std455
https://v8std.ru/std/455/

Общие требования к конфигурации

🟡Используйте только штатные и документированные возможности платформы.

🟡Закладывайте работу в разных средах: СУБД, ОС, браузеры.

🟡Исправляйте ошибки проверки конфигурации, исключения — только по стандартам.

🟡Поддержите минимальную работу в обычном приложении для администраторов.

🟡Не оставляйте мертвый код и мертвые метаданные.

🟡Сортируйте метаданные по имени, а подчиненные — по проектной логике.

#std467
https://v8std.ru/std/467/

Ограничение на использование оператора Перейти

🟡Перейти ухудшает читаемость и структуру кода.

🟡Используйте Если, Иначе, Возврат, циклы — это проще и надежнее.

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

#std547
https://v8std.ru/std/547/

Правила создания модулей форм

🟡В модуле формы держите только код, который работает именно в контексте этой формы.

🟡Не делайте экспорт в форме: публичный интерфейс — в общих модулях и модулях объектов/менеджеров.

🟡Параметры формы передавайте через ОткрытьФорму, результат — через оповещения, не через экспортные методы.

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

🟡Если логика нужна и на клиенте, и на сервере — делайте одну процедуру &НаКлиентеНаСервереБезКонтекста и передавайте контекст параметром.

#std630
https://v8std.ru/std/630/

Структуры и таблицы значений в параметрах

🟡Для сложных параметров делайте функцию‑конструктор: она возвращает структуру‑заготовку или пустую таблицу с типизированными колонками.

🟡Вызывающий код только заполняет значения и передает их в основную функцию.

🟡Имена свойств структуры должны совпадать с параметрами функции; значения по умолчанию задавайте в конструкторе.

🟡Состав и типы параметров фиксируйте в описании (для библиотек — с перечислением свойств/колонок).

🟡Не добавляйте новые свойства/колонки на стороне вызова — это источник скрытых ошибок.

#std641
https://v8std.ru/std/641/

Работа в разных часовых поясах

🟡Операции выполняйте по времени пользователя, а не сервера.

🟡В серверном коде используйте ТекущаяДатаСеанса, а не ТекущаяДата.

🟡Когда нужно время вне часового пояса сеанса — используйте УниверсальноеВремя.

🟡На клиенте не вызывайте ТекущаяДата; передавайте дату с сервера или берите из документа.

🟡Не вызывайте ТекущаяДатаСеанса несколько раз подряд — сохраните значение и используйте его.

#std643
https://v8std.ru/std/643/

Имена процедур и функций

🟡Имена берите из предметной области — они должны объяснять назначение без комментариев.

🟡Пишите слитно, каждое слово с заглавной буквы; предлоги тоже с заглавной.

🟡Не включайте типы в названия, если это не критично для смысла.

🟡Процедуры называйте глаголом: ЗагрузитьКонтрагента.

🟡Функции называйте по результату: ПолноеИмя, ДатаНачалаСеанса.

🟡Если функция создает объект — используйте Новый....

🟡Функции‑проверки называйте Это... или причастием.

#std647
https://v8std.ru/std/647/

Обращения к виртуальным таблицам

🟡Все условия, относящиеся к виртуальной таблице, передавайте в ее параметры, а не в ГДЕ.

🟡Так СУБД быстрее выберет план и не обработает лишние записи.

🟡В параметрах используйте простые условия вида Измерение = Значение.

🟡Подзапросы и соединения в параметрах — только в исключениях и по строгим правилам.

🟡Если условий с подзапросами много — оставьте одно самое фильтрующее, остальные перенесите наружу или используйте временную таблицу.

#std657
https://v8std.ru/std/657/