- [Стандарт 1С: Описание процедур и функций](https://its.1c.ru/db/v8std#content:453:hdoc)
- [Доклад про систему расчета типов и многое другое...](https://youtu.be/Hwzn_O_oSow)
- [Доклад про систему валидации](https://developer.1c.ru/applications/Console/devcon/2-12.html)
### Расчетная типизация
Динамический расчет типов, выполняемый в 1С:EDT на основе контекста 1С:Предприятия и метаданных конфигурации.
#### Отслеживание состояния типов переменных
Система типизации кода 1C:EDT отслеживает тип переменных в зависимости от их использования (местоположения в коде)
```bsl
МояПеременная = 10;
...
Если МояПеременная > 0 Тогда // В этом месте тип - Число
КонецЕсли;
...
МояПеременная = Истина;
...
Если МояПеременная Тогда // В этом месте тип - Булево
КонецЕсли;
```
#### Отслеживание состояния типов свойств
При анализе объектов данных (Data-flow analysis), создаваемых программно, система типизации 1C:EDT учитывает только те типы, которые были указаны в момент инициализации свойства в объекте данных.
```bsl
Параметры = Новый Структура("МоеСвойство"); // Инициализация без указания начального типа
...
Параметры.МоеСвойство = 10; // Смена типа с Неопределено на Число не происходит
...
Если Параметры.МоеСвойство > 0 Тогда // В этом месте тип МоеСвойство - Неопределено
При фактической смене типа значения у свойства объекта, который допускает такое поведение в run-time `1С:Предприятия 8`, система типизации и анализа объектов данных в 1C:EDT не учитывает эту смену.
В этом случае, правильным подходом является: указание начального типизированного значения, и не допускать изменения типа значения далее в коде. Т.е., фактически - есть два варианта у переменных:
1. Тип определен пользователем явно, и дальше он меняться не будет, а попытку изменения - можно будет отслеживать.
2. Если тип неопределен явно, то он ВСЕГДА будет неопределен и далее, и плагин будет во всех местах его считать именно неопределенным. Фактически - данный подход запрещает использовать конструкцию ```Перем``` без явного указания типа в комментарии.
Статическое указание типов в документирующих/типизирующих комментариях, ссылки на функции-конструкторы и ссылки на входящие параметры других методов.
### Инструментарий
Существуют стандартные инструменты в 1C:EDT и добавляемые расширениями (плагинами) инструменты, которые помогают типизировать код.
#### Использование контекстного помощника ввода
Документация по [Контекстной подсказке](https://its.1c.ru/db/edtdoc#content:323:hdoc)
1. Для того, чтобы код был максимально типизирован изначально - при написании кода следует использовать контент-ассист (или контекстный помощник ввода) Ctrl+Space, который подсказывает все известные свойства и методы объекта.
2. При этом, если помощник ввода не подсказывает нужные свойства - следует сначала уточнить типы (исправить типы) для текущего объекта и продолжить набор текста по известным свойствам.
3. Использование типизации кода снижает потребность написания кода в режиме отладки с целью определения типов переменных, т.к. типы переменных подсказывает среда разработки.
4. Для проверки, того, что объект имеет статический или динамический тип - необходимо выделить нужный объект и нажать `F2` для отображения описания объекта - перед именем объекта должен отображаться его тип.
5.**Важно!** Типизирующие комментарии не могут переопределять типы, которые рассчитала EDT, а могут только их дополнять. Это значит, что если вы укажите в комментарии к функции что вы ожидаете на вход тип, например `ПолеВвода`, а в контекстной подсказке у вас показываются методы других типов, например, `ГруппаФормы`, то это значит, что EDT нашла места вызова этой функции, в которых передается другой тип. И это убрать или переопределить типы - нельзя на текущий момент.
- в коде после точки обращения к свойству/методу вызвать контент-ассист (нажать `Ctrl+Space`) - подсказка ввода не показывает свойства в формате `Объект.Свойство <Тип свойства> ~ Тип объекта`
> **Обратите внимание!** В подсказке ввода - после имени свойства указан тип свойства `<Тип свойства>` в фигурных скобках и после ` ~ Тип объекта` - тип, из которого это свойство получено, т.к. у объекта может несколько типов.
1. Необходимо найти самый первый объект в цепочке вызова в данной строке
2. Высянить есть ли у этого объекта тип - навести мышкой или нажать `F2` для вывода подсказки
3. Перейти к определению этого объекта - нажать `F3` и в месте определения выяснить тип
4. Определить тип слишком общим (абстрактным), например, `УправляемаФорма`, `ТаблицаЗначений`, `Массив`, `Структура`, `ДокументОбъект`, `СправочникСсылка` и т.д. без спецификации каких либо конкретных свойств к которым необходимо обращаться
5. Корректно ли написан типизирующий документирующий комментарий
6. Если типы корркетные - следует начиная от места определения объекта/переменной до места потери типа - проверить все места использования: пере-присвоения значения переменной, передача её в вызов метода и т.д.
#### Генератор документирующих комментариев
Документация по [Генератору документирующего описания методов](https://its.1c.ru/db/edtdoc#content:330:hdoc)
1. Позволяет сформировать начальное документирующее описание метода, чтобы далее легче было до-редактировать
2. Заполняет известные типы входящих параметров или возвращаемых значений на основе расчетной типизации кода текущего модуля
3. Позволяет до заполнить отсутствующие секции или параметры в существующем документирующем комментарии и выполняет стандартное форматирование с учетом модели данных. Это позволяет увидеть ошибочно написанные конструкции, которые не соответствуют формату документирующего комментария
Позволяет увидеть структуру данных документирующего комментария, так как её считывает 1C:EDT, увидеть расхождения с тем, что ожидал разработчик и тем что он написал.
Кратко: это контроль (валидация) наличия всех типов, как декларативных, так и динамически-рассчитанных, в коде `1С:Предприятия 8`. Этот контроль предоставляется расширением "1С:Стандарты разработки V8" для 1С:EDT.
Ключевые возможности:
- Контроль наличия типов в месте создания объекта, переменной
- Контроль наличия типов в месте использования (обращение к свойствам или методам объекта)
- Контроль типов возвращаемых значений для функций, свойств объектов, переменных
- Запрет смены типов для переменных, и свойств объектов
- Пересечение типов при передаче объектов в параметры вызываемого метода
- Контроль декларируемых типов и типов из системы "анализа потока данных" ([Data-flow analysis](https://star-wiki.ru/wiki/Data-flow_analysis), DFA) для "пользовательских" объектов данных, т.е. специфичных структур и таблиц значений, создаваемых пользователем в коде
- Возможность включать "строгую типизацию" только в выбранных модулях, или для проекта в целом
#### Чем не является "Строгая типизация"
- Не ООП
- Не добавляется иерархия типов 1С, и не меняется если иерархия есть
- Не добавляется понятия абстрактных объектов, или "Интерфейсов" для общего поведения объектов и их "реализация" в конкретных объекта
- Не меняется система типов `1С:Предприятия 8` - только контролируется существющие типы
#### Аналогия TypeScript и JavaScript
У многих разработчиков `1С` возникает справедливая ассоциация с языком `TypeScript`. При разработке "Строгой типизации" мы действительно "подглядывали" в связку этих двух языков `TS + JS`.
Подробнее про [TypeScript здесь](https://ru.wikipedia.org/wiki/TypeScript).
В чем "Строгая типизация 1С" похожа на `TypeScript`:
- Результирующий код 1С - всё так же исполняется в 1С:Предприятии, как `TypeScript` после компиляции исполняется в браузере
- Статическая типизация проверяется в языке `1С:Предприятия 8`
- Типы теперь необходимо записывать, если их невозможно вычислить. Не имеет значения в каком формате запись - через "двоеточие" или через "два слеша", до переменной или после - это "вопрос вкуса", главное - типы необходимо где-то записать.
- Ошибки типизации отображаются только в IDE, при этом в run-time `1С:Предприятия 8` смена типа по-прежнему возможна
- В рамках одного приложения можно только в одном/некоторых модулях включить "Строгую типизацию" - остальные модули могут быть по-прежнему слабо-типизированными
- Взаимодействие модулей "Строгой типизации" с модулями без "строгой типизации" по прежнему возможно, аналогично как `TypeScript` взаимодействует с модулями JS
В чем отличие "Строгой типизации" от `TypeScript`:
- Нет процесса трансляции/компиляции (Trans-piling) в язык 1С - модули со строгой типизацией исполняются "как есть" в run-time `1С:Предприятия 8`
- Не добавляется ООП в язык 1С, т.к. это противоречит идеологии языка `1С:Предприятия 8`
- Не добавляется поддержка "библиотек" (модулей), при этом понятие "модулей" в `1С:Предприятия 8` присутствует - тут 50/50, не стоит холиварить на эту тему.
- "Строгая типизация" не добавляет никаких функциональных возможностей в язык `1С:Предприятия 8`
- Не добавляются "Интерфейсы" в язык `1С:Предприятия 8`
При использовании дополнительного расширения "1С:Стандарты разработки" для 1С:EDT рекомендуется для модуля включить строгую типизацию, которая будет контролировать, что все типы были созданы правильно, во всех местах используется жесткие ссылки на объекты-создатели, что нет смены типа у переменной.
Контроль типизации будет выполняться для всего модуля, включая не экспортные методы. Контролируется наличие типов всех переменных, используемых вызовов общих модулей, при обращении к полям/свойствам объектов контролируется их наличие и их типы.
Это означает, что для не экспортых методов необходимо писать типизирующие документирующие комментарии для входящих параметров и типы возвращемых значений функций, если код написан не прозрачно для анализа системы типизации 1C:EDT. Написание текстов описаний методов и параметров для других разработчиков - не является обязтельным в контексте типизации кода.
Далее 1C:EDT будет отображать ошибки, если с объектами и их типами что-то не корректное.
**Групповое включение** строгой типизации можно выполнить командой `Включить строгую типизацию (@strict-types) в модулях` в контекстном меню:
- в навигаторе 1С: для проекта в целом, для выделенного списка объектов метаданных
- в навигаторе файлов (Project Explorer): для выделенного списка каталогов или файлов модулей
- в редакторе модуля - подменю Source: для текущего открытого модуля
#### Применение строгой типизации
В каких случаях рекомендуется применять:
- Для всех новых конфигураций, не имеющих большого наследия не типизированного кода, для всех модулей следует включать строгую типизацию.
- Для существующих модулей рекомендуется сначала выполнить адаптацию кода и после включить строгую типизацию.
Стандарт 1С [Описание процедур и функций](https://its.1c.ru/db/v8std#content:453:hdoc) п.2 требует наличие описания только программного интерфейса. Это означает, что:
- для экспортных методов из области `"ПрограммныйИнтерфейс"` необходимо указывать описание смысла методов и параметров для программиста, так же обязательное указание типов
- для экспортных служебных методов (из любых других областей модуля) обязательно только указание типизирующих документирующих комментариев
### Расширение типов
Система типизации кода в 1C:EDT работает по принципу расширения типов, собирая информацию о типах из всех возможных источников.
```bsl
МояПеременная = ФункцияРазличныхТипов(Ложь); // Булево - добавляем ещё тип
В данном примере - EDT сама рассчитает 2 типа - `Массив|Число`, и, при помощи коментария - мы расширим тип переменной `МояПеременная` до третьего типа - `Булево`.
Теперь - EDT позволит вам выполнять любые действия над этой перменной, если это действие можно выполнить хотябы над одним типом (рассчитанным EDT, или добавленным вами через типизирующий комментарий).
### Сокращение типа локальной переменной или параметра
- Можно безопасно сократить (или фактически установить для статического анализатора) тип локальной переменной метода, входящего параметра или переменной модуля (объекта, формы) метода через проверку типа:
```bsl
Если ТипЗнч(МояПеременная) = Тип("СправочникОбъект.Товары") Тогда
МояПеременная.Артикул = "";
МояПеременная.Записать();
```
при этом внутри условия переменная будет указанного в проверке типа, как в рантайме, так и для статического анализатора. Условие проверки должно быть простым.
Для задачи переопределения расчетных типов на основе кода, которые считает система 1C:EDT, необходимо указать в документирующих комментариях тип входящего параметра.
Следует учитыать, что для метода система типизации 1C:EDT собирает все локальные вызовы в текущем модуле и анализирует типы передаваемые в вызов - внутри метода тип параметра будет расчетный, но при вызове локальной метода система строгой типизации будет отображать ошибку несоответствия типов:
В этом случае, переменная `Док` будет уже иметь два расчетных типа. Например, если у документа `РасходТовара` нет реквизита `Автор` и нет функции в модуле объекта `ВернутьМакет`, то в теле метода никаких ошибок.
Если есть цель выяснить - будут ли проблемы при передачи нового типа в функцию, необходимо код писать безопасно, с проверкой типа параметра:
## Возможности типизирующих документирующих комментариев
- [Комментирование процедур и функций](https://its.1c.ru/db/edtdoc#content:330:hdoc)
- [Стандарт 1С: Описание процедур и функций](https://its.1c.ru/db/v8std#content:453:hdoc)
Документирующие комментарии необходимы для 2х целей:
1. Декларирование типов входящих параметров и возвращаемых значений функций
2. Описание назначения процедуры, параметров и полей для разработчиков
1C:EDT поддерживает решение этих целей независимо друг от друга: можно писать описания без типов, или типы без описаний, или комбинация типов и описаний.
### Описание структуры данных док.коммента
Структуру данных документирующего комментария можно представить в следующем упрощенном иерархическом виде:
```yml
Description: # Объект описания, состоящий из коллекции строк и ссылок
- TextPart # Текстовая строка описания
- LinkPart # Ссылка на сайт или на метод конфигурации
ParameterSection: # Секция параметров метода, у секции может быть свою описание
Description:
- ...
ParameterDefinitions: # Список параметров
- FieldDefinition:
Name: ParameterName # Имя параметра
Description: # Описание параметра
- ...
TypeSections: # Список секций типов, может быть несколько
- TypeSection:
Description:
- ...
TypeDefinitions: # Список определений типов
- TypeDefinition:
TypeName: TypeName # Имя тип 1С
ContainTypes: # Список описаний типов элементов коллекций, если в определении указана колекция
- TypeDefinition:
...
- TypeDefinition
FieldDefinitionExtension: # Возможность расширить тип полями (для структур, ТЗ и т.д.)
- FieldDefinition:
...
- TypeDefinition
- LinkContainsTypeDefinition # Определение типа содержащего ссылку на функцию или параметр
LinkPart: LinkPart
- FieldDefinition:
...
CallOptionsSecton: # Секция параметров вызова
Description:
- ...
ExampleSection: # Секция примеров использования метода
Description:
- ...
ReturnSection: # Секция описания возвращаемого значения функции
Description:
- ...
ReturnTypes: # Список секций типов возвращаемых значений
- TypeSection:
Description:
- ...
TypeDefinitions:
- TypeDefinition:
...
- TypeSection:
...
```
Рассмотрим подробнее на примерах возможности документирующих комментариев.
Описание - многострочное, со ссылками
```bsl
// В описании рекомендуется писать все ссылки на отдельной строке.
Возможно указание описания для каждого типа поля/параметра, когда каждый тип записан с новой строки, через дефис-минус. Не допускается использование различных видов "тире" (длинных, коротких, средних и т.д.)
// Объект - СправочникОбъект.Товары - Здесь описание для типа
// - ДокументОбъект.РеализацияТоваров - Здесь описание для другого типа
Процедура ОбработкаОбъекта(Объект)
```
Простой вариант записи нескольких типов - через запятую
```bsl
// Параметры:
// Объект - СправочникОбъект.Товары, ДокументОбъект.РеализацияТоваров - Здесь описание для списка типов
Процедура ОбработкаОбъекта(Объект)
```
В простом случае - описание поля/параметра может быть многострочным
```bsl
// Параметры:
// Объект - СправочникОбъект.Товары - Здесь описание для типа
// Вторая строка описания параметра
Процедура ОбработкаОбъекта(Объект)
```
Описание единственного типа элементов коллекции
```bsl
// Параметры:
// Объект - Массив из СправочникОбъект.Товары - Здесь единственный тип элементов
Процедура ОбработкаОбъекта(Объект)
```
Описание составного типа элементов коллекции через запятую
```bsl
// Параметры:
// Объект - Массив из СправочникОбъект.Товары, ДокументОбъект.РеализацияТоваров -
Процедура ОбработкаОбъекта(Объект)
```
Возможность указывать расширение полей для типа, **строго после двоеточия** в конце однострочного описания
```bsl
// Параметры:
// Объект - Структура - Здесь нельзя многострочное описание:
// * ПолеСтруктруы - ТаблицаЗначений - Описание поля структуры, после опять раширение уже для таблицы:
// ** ИмяКолонки - Число - описание колонки таблицы
Процедура ОбработкаОбъекта(Объект)
```
Можно не писать описание, оставлять только типы и обязательное двоеточие
```bsl
// Параметры:
// Объект - Структура:
// * ПолеСтруктруы - ТаблицаЗначений:
// ** ИмяКолонки - Число
Процедура ОбработкаОбъекта(Объект)
```
Не всегда возможно правильно определять что сейчас "описание без типа" или "тип без описания", поэтом может требоваться указание дефиса после списка типов для явного опредлеения секции типов
```bsl
// Параметры:
// Объект - Структура, ТаблицаЗначений -
Процедура ОбработкаОбъекта(Объект)
```
В этом случае без секция со списком типов превращается в просто текстовое описание
В возвращаемом значении функции можно указывать ссылки на локальные не экспортные функции конструкторы объектов данных, если функция должна возвращать заполненный объект, но модуль не должен позволять через API создавать новый пустой объект данных
> **Внимание!** В целом, такой подход следует считать исключеним и не практиковать в коде, если возможно спроектировать код более прозрачно для вычисления типов.
Здесь собраны примеры решения различных задач типизации.
Если вы не нашли здесь какой-либо случай, но самостоятельно разобрались как правильно решать - просим вас [добавить пример на эту страницу](https://github.com/1C-Company/v8-code-style/blob/master/docs/checks/code_typification.md) через [контрибутинг](../contributing/readme.md) в проект.
- Запрещается инициализация переменных через `Перем` т.к. такая переменная инициализируется с типом `Неопределенно` и дальнейшая смена типа значения может быть не видна для статического анализатора
- Запрещается инициализировать переменные внутри циклов или условий и последующим использованием их вне циклов/условий - т.к. 1С:Предприятие создает все локальные переменные сразу при входе в процедуру - то статическому анализатору невозможно отследить, где была создана переменная и с каким типом
- Уточнение типа локальной переменной, инициализированной, например, функцией возвращающей более общий тип, возможно через указание типа в строке:
НЕПРАВИЛЬНО:
```bsl
// Создает новый объект Номенклатуры по переданному типу
Текущей функциональностью 1C:EDT является запись типа в одну строку в комментарии - что исключает местное описание сложных объектов данных (ТЗ, Структура, массив из структур) - для них необходимо использовать ссылки на функции конструкторы этих объектов.
ПРАВИЛЬНО:
```bsl
МойОбъект = Параметры.МойОбъект; // см. НовыйОбъектДанных
```
Допускается применение типизатора созданного через `Новый ОписаниеТипов(...)` для формирования переменных с необходимым типом начального пустого значения.
ПРАВИЛЬНО:
```bsl
Типизатор = Новый ОписаниеТипов("СправочникСсылка.Номенклатура,СправочникСсылка.НоменклатураПоставщика");
Переменные модуля объекта, формы, конфигурации, включая глобальные переменные (экспортные), следует объявлять со статическим указанием типа в комментарии. Также следует инициализировать переменную модуля начальным/пустым значением в коде модуля (после всех процедур и функций). Для модуля формы допускается инициализация начального/пустого значения в обработчиках событий `ПриСозданииНаСервере` для серверных переменных и в обработчике `ПриОткрытии` для клиентских переменных.
Исключением могут быть не экспортные переменные модуля, используемые только внутри общих механизмов и не имеющие обращений внутри текущего модуля объекта или формы.
НЕПРАВИЛЬНО:
```bsl
#Область ОписаниеПеременных
&НаКлиенте
Перем КэшированныеЗначения; //используется механизмом обработки изменения реквизитов ТЧ
&НаКлиенте
Перем ТекущиеДанныеИдентификатор; //используется для передачи текущей строки в обработчик ожидания
&НаКлиенте
Перем ПараметрыДляЗаписи Экспорт;
#КонецОбласти
```
ПРАВИЛЬНО:
```bsl
#Область ОписаниеПеременных
//используется механизмом обработки изменения реквизитов ТЧ
&НаКлиенте
Перем КэшированныеЗначения; // см. ОбработкаТабличнойЧастиКлиентСервер.ПолучитьСтруктуруКэшируемыеЗначения
//используется для передачи текущей строки в обработчик ожидания
- Значения ключей структуры (как в конструкторе, так и при добавлении в структуру) должны быть инициализированы сразу с пустым значением того типа, который будет использоваться в последствии. Динамическая типизация не позволяет рассчитать смену типа свойства структуры и, если не указывать пустое значение нужного типа, свойство будет инициализировано с типом Неопределенно.
- При добавлении ключа в существующую структуру следует писать код "прозрачно" для статического анализатора, таким образом чтобы вставка ключа и его использование были в одной области видимости.
- Допускается использовать безопасный доступ к полю структуры в случае, когда структура чужая по отношению к текущему коду и описать поля и их типы нет возможности. Если необходимо безопасно проверить наличие ключа, если ключ опционален. Такой код является кандидатом для рефакторинга.
```bsl
Процедура Обработка()
Если Структура.Свойство("МоеСвойство") И ЗначениеЗаполнено(Структура.МоеСвойство) Тогда
МоеСвойство = Структура.МоеСвойство; // СправочникСсылка.Номенклатура - явное указание типа для неизвестного поля структуры
...
```
Функциональность будет реализована в 1C:EDT будущих версий.
- Ограничение на получение значение ключа через метод "Свойство" не следует использовать: выглядит неплохо, но не анализируемая типизация
НЕПРАВИЛЬНО:
```bsl
Процедура Обработка()
Перем МояПеременная;
Если Структура.Свойство("МоеСвойство", МояПеременная) И МояПеременная = "Полученное значение" Тогда
...
```
ПРАВИЛЬНО:
```bsl
Процедура Обработка()
МояПеременная = "";
Если Структура.Свойство("МоеСвойство", МояПеременная) И МояПеременная = "Полученное значение" Тогда
- В общем случае - запрещено создавать массив `Новый Массив;` без указания типа его значений, если далее в коде текущего модуля происходит обращение к элементам массива.
НЕПРАВИЛЬНО:
```bsl
СписокСсылок = Новый Массив;
СписокСсылок.Добавить(Ссылка);
...
Для каждого Ссылка из СписокСсылок Цикл
Объект = Ссылка.ПолучитьОбъект();
...
```
ПРАВИЛЬНО:
```bsl
СписокСсылок = Новый Массив; // Массив из СправочникСсылка.Номенклатура -
СписокСсылок.Добавить(Ссылка);
...
Для каждого Ссылка из СписокСсылок Цикл
Объект = Ссылка.ПолучитьОбъект();
...
```
ПРАВИЛЬНО:
```bsl
СписокСсылок = НовыйСписокНоменклатуры();
СписокСсылок.Добавить(Ссылка);
...
Для каждого Ссылка из СписокСсылок Цикл
Объект = Ссылка.ПолучитьОбъект();
...
// Возвращаемое значение:
// Массив из СправочникСсылка.Номенклатура
Функция НовыйСписокНоменклатуры()
Возврат Новый Массив;
КонецФункции
```
- Не рекомендуется использовать в качестве значений объекты разных типов: строки с числами, простые типы со ссылочными, объекты БД и структуры и т.д.
- Если значение массива сложное, рекомендуется использовать функцию-конструктор для инициализации пустого массива или массива с данными
- Если в функции создается массив и наполняется значениями, допустимо описывать возвращаемое значение типов элементов массива в описании функции, если в самой функции не происходит обращения к элементам массива.
- В общем случае запрещается использовать описание типа `ТаблицаЗначений` в качестве входящего параметра экспортного метода, с описанием колонок. Правильно использовать ссылку на функцию-конструктор создающий эту таблицу.
- Исключением могут быть методы обрабатывающие произвольные таблицы, место создания которых неизвестно, но код метода рассчитывает на наличие определенных колонок. Все колонки, на которые рассчитывает код, с их типами должны быть указаны в документирующем описании.
- Исключением являются методы обрабатывающие таблицу значений с неопределенным набором колонок, например "копирование таблицы в структуру", при этом код не обращается к колонкам напрямую `СтрокаТЗ.Номенклатура = ...` а использует для обращения список колонок, сформированный в рантайме `СтрокаТЗ[ИмяКолонки] = ...`.
- Соответствие - это фактически сложный тип с фиксированным набором колонок (ключ и значение) или аналогичен массиву из структур с 2 колонками. При этом описание типов у ключа и значения есть по умолчанию - `Произвольный`, и необходимо создавать функцию конструктор которая инициализирует соответствие и описывает типы ключа и значения.
- Следует избегать комбинации [различных типов в ключе и в значении соответствия](#ограничения-составных-типов).
// Создаем данные фукнцией-конструтором и заполняем
Данные = НовоеСоответствие();
...
ПоместитьВоВременноеХранилище(Адрес, Данные);
...
// При инициализации переменной указываем ссылку на сходную функцию создавшую типизированный объект
МояПеременная = ПолучитьИзХранилищаЗначения(Адрес); // См. НовоеСоответствие
...
```
### Описание списка значений
- СписокЗначений - это фактически сложный тип с определенным элементом коллекции, у которого типизируется только одно свойство "Значение". При этом описание типов у значения есть по умолчанию - `Произвольный`, и необходимо создавать функцию конструктор которая инициализирует список и описывает типы значения.
- Если список значений используется для передачи данных наружу из текущей фукцнии в которой был создан - следует использовать возвращаемое значение функции-конструктора нового пустого списка или функции-получателя с заполненными данными в списке.
- Как в случае с `Соответствие` нет возможности указать тип значения для инициализируемой переменной в строке
Для сложных типов, создаваемых на основе абстрактных платформенных типов (`Структура`, `Соответствие`, `ТаблицаЗначений`, `ДеревоЗначений` и др.), следует использовать функцию-конструктор данных.
Наименование функции следует выбирать как `Новый`/`Новая`/`Новое` (`New`) и наименование объекта данных.
ПРАВИЛЬНО:
```bsl
// Возвращаемое значение:
// ТаблицаЗначений:
// * Номенклатура - СправочникСсылка.Номенклатура
Функция НоваяТаблицаОтобраннойНоменклатуры()
....
КонецФункции
```
- Конструктор данных может так же выполнять функцию заполнения данных т.е. предоставлять новый объект с заполненными данными. Например, функция выполняет запрос к БД и возвращает таблицу значений с колонками и данными.
При описании параметра метода следует указывать ссылку на функцию-конструктор данных без указания исходного базового типа данных (структура, таблица значений и т.д.).
При обработке более общих типов объектов в общих модулях может потребоваться получить заранее известный комплексный тип (`Структура`, `ТаблицаЗначений`, `ДеревоЗначений`), при этом, функции-конструктора таких данных может не существовать, например, когда данные создаются объектом метаданных, формой, СКД и так далее. Для таких случаев следует использовать функцию-получатель, описывающую тип возвращаемого значения со всеми необходимыми свойствами/полями объекта.
#### Ограничение на использование Функций-конструкторов
- Не следует создавать фиктивные функции-конструкторы, лишь для целей ссылки на возвращаемые типы. Следует проектировать код таким образом, чтобы функции-конструкторы создавали или получали объекты.
- Функции-конструкторы данных являются частью работы какого-либо объекта метаданных или функциональной подсистемы - поэтому должны располагаться в коде модулей этих объектов/подсистем.
- Созданный объект данных в текущем модуле передается в другой модуль или возвращается экспортной функцией - является частью API этого модуля.
Для параметров экспортных методов рекомендуется указывать ссылку на функцию-конструктор таких объектов.
Не рекомендуется указывать в качестве параметров не экспортных методов сложные типы на основе `Массивов`, `Таблиц Значений`, `Структур` и т.д., если объект является цельным, созданным в текущем модуле и контекст передачи объекта ограничен текущим модулем. В этом случае 1C:EDT не выполняет динамическую типизацию таких параметров, а использует указанные статические типы в описании метода.
Допускается описание таких типов во входящих параметрах, если описывается часть объекта или программный интерфейс объекта, например несколько колонок `ТЧ.Товары` для которых выполняется расчет, при этом не существует одной единой функции-конструктора на которую можно сослаться в описании.
Существует понятие "описания программного интерфейса объекта" и его реализация в прикладных объектах конфигурации. С применением библиотечного подхода к разработке конфигураций, библиотека может описывать некий программный интерфейс который должен быть реализован в прикладном объекте, для того чтобы библиотечный механизм имел доступ к объекту.
Например, механизм "Свойства" из библиотеки БСП описывает интерфейс объекта: Наличие табличной части `ДополнительныеРеквизиты`, содержит колонки `Свойство`, `Значение`, `ТекстоваяСтрока` с определенными типами. Далее общий механизм библиотеки может обращаться к объекту например, при записи `УправлениеСвойствами.ПередЗаписьюНаСервере(ЭтотОбъект, ТекущийОбъект);` объекта из формы.
Следует описывать интерфейс входящего объекта для той части объекта, которая требуется для работы механизма. При этом, следует учитывать, что механизм расширений свойств в документирующих комментариях поддерживается для тех типов, у которых возможны пользовательские свойства. Например: элементы коллекции вместо самих коллекций - тип `ТабличнаяЧасть` не имеет пользовательских свойств, а тип `СтрокаТабличнойЧасти` может иметь; тип `ДанныеФормыКоллекция` не имеет пользовательских свойств, а тип `ДанныеФормыЭлементКоллекции` может иметь.
- Допускается описание части формы, общие для нескольких форм или реализация некого интерфейса для общего механизма конфигурации. Например, части одного общего механизма, подключенные к множеству объектов конфигурации (дополнительные реквизиты, контактная информация и т.д.).
- Для функций общих модулей, рассчитывающих на дополнительные свойства и методы расширения типа `ФормаКлиентскогоПриложения` следует использовать соответствующие типы расширений управляемой формы: `РасширениеУправляемойФормыДляОбъектов`, `РасширениеУправляемойФормыДляДокумента`, `РасширениеУправляемойФормыДляДинамическогоСписка` и так далее.
- При использовании методов `ПолучитьФорму()` и `ОткрытьФорму()` с присвоением возвращаемого значения формы после открытия - следует указывать строковый литерал с полным именем формы первым параметром.
- Не следует выносить строковый литерал в отдельную переменную т.к. в этом случае переменная форма будет содержать общий тип `ФормаКлиентскогоПриложения` а не конкретный тип формы справочника номенклатуры, и весь контекст формы не будет доступен. В 1C:EDT на текущий момент поддерживается полная типизация только для полных имен форм, ссылки на основные формы для объекта метаданного `ФормаОбъекта`, `ФормаСписка` и т.д. возвращают общий тип `ФормаКлиентскогоПриложения`, полная типизация может быть поддержана в будущих версиях.
- Все параметры методов и возвращаемые значения функций должны содержать описания типов, при этом пояснения к параметрам следует описывать в соответствии со [стандартом](https://its.1c.ru/db/v8std#content:453:hdoc)
- Локальные процедуры и функции не обязаны содержать описаний типов в документирующих комментариях и могут быть полностью расчетными, если код написан прозрачно для статического анализатора.
- В случае разрыва прямого вызова методов в рамках одного модуля (когда из одного метода напрямую вызывается другой метод) - следует описывать типы входящих параметров для не экспортных методов.
- Поместить во временное хранилище и после получить из него - можно все что угодно, поэтому необходимо выделять функцию возвращающую тип помещенный во временное хранилище использовать на нее ссылку при получении:
```bsl
Данные = ПолучитьИзВременногоХранилища(Адрес); // см. НовыйОбъектДанных
- Аналогичный подход следует использовать при помещении пользовательского объекта внутрь другого объекта-контейнера, например `ДополнительныеПараметры` у объектов, или `Параметры` формы, пользовательские параметры элементов `СКД`, `ДополнительныеПараметры` у обработчиков оповещения и так далее.
Не следует обращаться к элементу именованной коллекции, например `ВсеЭлементыФормы` и другие, через строковый индекс с именем элемента. Вместо этого следует обращаться напрямую к элементу так как в этом случае статический анализатор может контролировать наличие элемента, его тип.
НЕПРАВИЛЬНО:
```bsl
Элементы["Наименование"].Видимость = Ложь;
```
ПРАВИЛЬНО:
```bsl
Элементы.Наименование.Видимость = Ложь;
```
Исключением может быть:
* обращение к элементам и свойствам создаваемым программно и в момент статического анализа их еще не существует. При этом следует указывать тип локальной переменной полученного значения и уже потом обращаться к ее свойства:
НЕПРАВИЛЬНО:
```bsl
Элементы["Наименование"].Видимость = Ложь;
Элементы["Наименование"].Доступность = Истина;
```
ПРАВИЛЬНО:
```bsl
Элемент = Элементы["Наименование"]; // ПолеФормы -
Элемент.Видимость = Ложь;
Элемент.Доступность = Истина;
```
* наличие таких элементов в коллекции может быть опциональным, при этом выполняется проверка наличия элемента. Например: исходный объект с неопределенными свойствами создается где-то вне и передается в текущую функцию входящим параметром.
Реквизит формы с типом `Произвольный` в коде следует рассматривать как "черный ящик". Статический анализатор не отслеживает изменение типа реквизита формы, поэтому весь обслуживающий этот реквизит код должен использовать проверку типа значения.
В общем случае не следует использовать реквизит с типом `Произвольный` на форме, т.к. при этом разработчик самостоятельно несет ответственность за инициализацию значения в этом реквизите, за то, что все типы данных хранимые в реквизите могут быть сериализованы/десериализованы при передаче с клиента на сервер и обратно. Так же значение реквизита будет передаваться между клиентом и сервером всегда т.к. Платформа не контролирует модификацию значений, например внутри структуры, помещенной в произвольный реквизит.
Реквизит с типом `Произвольный` следует заменять на честные реквизиты формы с определенными типами. Исключением может быть хранимые данные общих механизмов библиотек, которые через программный интерфейс инициализируют и обрабатывают хранимое в этом реквизите значение.
Если заменить реквизит с типом `Произвольный` нет возможности, следует использовать функцию-конструктор для инициализации значения и дальнейших ссылок на типы. При этом не следует напрямую обращаться к реквизиту - для получения значения следует использовать функцию-получатель.
При типизации выборки/выгрузки из результата запроса следует использовать возможности:
1. Статическое описание всех полей выборки (полей таблицы значений выгрузки) в возвращаемом значении [функции-получателе данных](#функции-получатели-сложных-объектов-данных). Может применяться для функций, динамически формирующих текст запроса и выборку, а так же все экспортные функции, возвращающие выборку.
2. Динамическая типизация полей выборки на основе текста запроса. В будущих версиях 1C:EDT может быть реализована возможность обращаться к полям запроса, при условии что текст запроса и выборка (результат запроса) находятся в одной процедуре, текст запроса не содержит ошибок (открывается "Конструктором запросов"), выборка/выгрузка из результата запроса не передается в другой модуль для обработки.
Объекты данных созданные пользовательским кодом и использованные вне текущего модуля - должны быть описаны функцией возвращающей значение.
Использование типа созданного в текущем модуле, но не предназначенного для создания в другом модуле - следует использовать не экспортную функцию-конструктор, при этом существует 2 варианта:
1. Экспортная функция, которая возвращает это значение вместе с данными (функция-получатель) - в ней нужно в возвращаемом значении указать функцию-конструктор
2. Реализация какого-либо интерфейса из переопределяемого модуля - в этом случае, можно использовать ссылку на параметр
- Существуют процедуры которые создают ТЗ или структуру аналогичную какому-нибудь объект метаданных, далее выполняется копирование значений для каждого свойства
- Не рекомендуется, т.к. Необходимо будет описать весь объект самостоятельно
- В исключительных случаях (каких?) можно сделать функцию-конструктор описывающую смешанный тип `Структура + СправочникОбъект.Номенклатура` чтобы не описывать весь тип. При этом можно добавить в описание дополнительные колонки, которые вводятся для технических целей (помощь при копировании, передача дополнительной информации с объектом).
- Следует учитывать ограничение на описание строк ТЧ объектов метаданных.
