Проект 1С:Стандарты разработки V8 поставляет категории в разрезе типов объектов в метаданных. Следует указывать категорию для каждой проверки из соответствующего бандла, где размещен класс проверки.
CamelCase
т.к. он менее читабельный.common-module
, catalog
, role
и т.д.) что бы не допустить неоднозначности толкования к чему применяется проверкаv8codestyle
) в коде проверки не используетсяСледует отражать в коде проверки находимую проблему или группу проблем (если проверка выполняет множество однотипных проверок).
Код проверки не должен состоять лишь из имен найденных объектов.
НЕПРАВИЛЬНО:
Здесь ключ проверки отражает только имена объектов, которые проверяет:
module-method-check
function-type-check
Не следует в коде проверки отражать процесс поиска проблемной ситуации.
НЕПРАВИЛЬНО:
check-method-usage
ПРАВИЛЬНО:
method-never-used
Это чуть более актуально для проверок по модулю - т.к. это будет везде визуально читаться.
Для других типов проверок (по метаданным) аналогичное правило подходит, хоть и не будет постоянно отображаться везде в интерфейсе (при открытии доп. формы).
НЕПРАВИЛЬНО:
//@skip-check check-method-never-used
ПРАВИЛЬНО
//@skip-check method-never-used
Следует избегать использования "слов-паразитов", которые не добавляют никакого смысла в код проверки, например слова: check, error, warning, артикли a, the, to, is, are и т.д. problem, valid
НЕПРАВИЛЬНО
check-method-is-empty
to-find-my-awesome-problem
ПРАВИЛЬНО:
method-empty
awesome-problem
Из кода проверки желательно сразу понимать к какому типу объектов она имеет отношение. Обычно это следует от типа ТОП-объектов (md, form, module/bsl, dcs, ql, moxel). Если проверка диагностирует проблему в подчиненном объекте имя которого уникально - можно не указывать префикс топ-объекта.
НЕПРАВИЛЬНО:
attribute-type-empty
parameter-name-too-short
ПРАВИЛЬНО:
form-attribute-type-empty
md-attribute-type-empty
method-parameter-name-too-short
form-parameter-name-too-short
module-standard-regions
function-has-no-return-type
check.descriptions/check-id.md
и check.descriptions/ru/check-id.md
с детальным описанием## См.
(или ## See
) в файлах описаний check-id.md
НЕПРАВИЛЬНО
и ПРАВИЛЬНО
которые находит проверка. Желательно использовать примеры из тестов.Тип найденной проблемы/диагностики
ERROR
- Ошибка в приложенииWARNING
- Предупреждение о проблеме в приложенииSECURITY
- Уязвимость в приложенииPERFORMANCE
- Проблема производительности приложенияPORTABILITY
- Проблема универсальности метаданных и кода приложения.LIBRARY_DEVELOPMENT_AND_USAGE
- Проблема внедрения библиотеки или нарушение принципов библиотечной разработки.CODE_STYLE
- Соглашения при написании кода, некачественный кодUI_STYLE
- Проблема проектирования UISPELLING
- Опечатка в тексте, коде, в именах метаданныхНеобходимо установить критичность найденной ошибки по умолчанию. Критичность необходимо устанавливать адекватную проблеме уровню проблемы в приложении.
BLOCKER
- ошибку необходимо исправлять немедленноCRITICAL
- Критичная проблема, необходимо исправлять в первую очередьMAJOR
- Обычная проблема, исправлять следует в обычном порядкеMINOR
- Незначительная проблемаTRIVIAL
- Тривиальная проблемаNORMAL
- Сложность алгоритма поиска ошибочной ситуации низкая, не выполняется обращение к объектам из других ресурсов.COMPLEX
- Большое количество вычислений, обращение к объектам из других ресурсовПринципы создания параметров: - Возможность внести исключения в правило поиска проблемных мест - Нет смысла в параметрах, если проверяется единственный объект и какое-либо исключение равно отключению проверки - Используйте паттерны в параметрах для поиска исключений - Любые константные значения (текстовые, числовые, с большой вариабельностью, Булево), которое имеют отношение к логике проверки, следует задавать через параметры
Типовые примеры: - Исключение по имени метаданного - Длина, количество символов и т.д. - числовые значения в проверке обычно являются кандидатами для вынесения в параметры
Соглашения при создании параметров: 1. имена параметров должны быть понятны в контексте проверки 2. имена параметров пишутся в сamelCase
, начиная с маленькой буквы, без пробелов, второе слово и далее с заглавной буквы 3. Константа с именем параметра должна быть публичной 4. Заголовок параметра должен быть локализован через NLS класс
com._1c.g5.v8.dt.check.components.BasicCheck
или аналогичных для специфичных областей com.e1c.g5.v8.dt.bsl.check.DocumentationCommentBasicDelegateCheck
, com.e1c.g5.v8.dt.ql.check.QlBasicDelegateCheck
com._1c.g5.v8.dt.check.components.IBasicCheckExtension
для переиспользования.com._1c.g5.v8.dt.check.components.ModuleTopObjectNameFilterExtension
, com._1c.g5.v8.dt.check.components.TopObjectFilterExtension
Добавьте одно из обязательных расширения проверок: - StandardCheckExtension
- для принадлежности проверки к функциональной опции включающей или отключающей проверки по 1С:Стандартам - CommonSenseCheckExtension
- для принадлежности проверки ко всем прочим полезным проверкам исходя из здравого смысла, "лучших практи" и т.д. которые не регламентируются стандартами 1С.
Текс ошибки должен отвечать на вопрос:
Примеры: 1. Переменная не была инициализирована 2. Конфигурация содержит некорректный режим блокировки данных 3. Метод пустой 4. Метод не используется 5. Длина имени объекта метаданного должна быть меньше чем 80
При регистрации проверки следует указывать все фичи, от которых зависит логика проверки - это означает, что при изменении любого из второстепенных свойств объекта будет выполнена перевалидация по текущей проверке.
Каждый корректный и ошибочный вариант должны быть добавлены в разделы "ПРАВИЛЬНО" и "НЕПРАВИЛЬНО" описания проверки
Если какая-либо проверка напрямую не описана в одном из стандартов, но при этом является полезной - такую проверку можно размещать в этом проекте.
Проверку следует регистрировать по умолчанию выключенной - таким образом каждый проект 1С:Предприятия может сам решить какие дополнительные проверки активировать.
Регистрация проверки не по стандарту, включенной по умолчанию, следует явно описывать в задаче (issue) в проекте, если контрибьютор считает, что ее необходимо активировать всегда.