В правила участия Contributing guide добавить ограничение на использование Stream

[marmyshev]

Раздел документации или код проверки

https://github.com/1C-Company/v8-code-style/tree/master/docs/contributing

1C:Code style V8 -> Руководство контрибутора -> Разработка проверок

Либо в раздел Соглашение при создании проверок добавить.

Либо создать отдельный подраздел касающийся кода.

Что необходимо улучшить

Часто разработчики используют Стримы/потоки для целей красоты кода, не думая о том, какую дополнительную нагрузку (память, процессор, GC, etc.) стримы привносят в проверку.

Необходимо описать правила, когда стоит использовать стримы, и когда это когда это явно запрещено, с примерами и объяснением.

Дополнительные материалы

• ?

[tretyakevich]

1. Большая просьба ко всем разработчикам проверок - по возможности не используйте сложные stream-конструкции. Основных причин две:

• Сложные конструкции по-настоящему раскрываются только при параллельном выполнении, в противном случае оверхед на инстанциацию множественных объектов/коллекций и большого уровня вложенности вызовов с различными проверками и контролем в случае массовых вызовов (а это именно наш случай) значителен и не компенсируется ускорением за счет разбиения задачи на подзадачи, выполняемые в отдельных потоках. При этом мы не рекомендуем использовать параллельные stream-операции в проверках вообще, поскольку EDT крайне серьезно нагружает ресурсы хоста параллельным выполнением проверок на различных объектах.
• Команда 1С:EDT периодически проводит ревизию оптимальности выполнения проверок с использованием механизмов профилировки и т.п. Сложные stream-операции ЗНАЧИТЕЛЬНО усложняют исследования за счет значительного роста стека вызовов (первое) и значительного размазывания нагрузки по отдельным веткам обработки.

[tretyakevich]

2. При использовании Stream-операций всегда нужно помнить то, зачем Stream-операции были введены в язык, и в каких случаях их использования приносит значимую пользу

• Первый и самый основной тест на правильность использования Stream-операций - действительно ли в вашей задаче есть коллекция данных, имеющих какую-то родственную природу. Типичные примеры задач, которые таковыми не являются: -- Реализация псевдо-ветвлений на индексированных/хэшированных коллекциях. Когда у вас есть строго ограниченный набор данных, которые прекрасно проверяются/возвращаются по крайне ограниченному набору индексов или ключей. Пример: есть два значения строк (например для русского и англ. варианта скрипта), которые нужно проверить в зависимости от варианта скрипта. Данная задача решается эффективно одним if-ом c else, и крайне неэффективно - stream-ами (инстанциировать коллекцию, сложить элементы, отфильтровать). При этом синтаксис stream-решения никогда не приблизится по читабельности к обычному if-у