Введение
Во время разработки не всегда удаётся следить за качеством кода и соответствием его стандартам. Да, есть АПК и SonarQube, но проверка происходить только после того как код помещается в хранилище или в git, что откладывает время обнаружения ошибок и отодвигает сроки закрытия технического долга. Более того, не все проекты подразумевают контур тестирования. В связи с этим в какой-то момент начались поиски решения, позволяющего:
-
Дополнить инструментарий разработчика по проверке кода на соответствие стандартам и здравому смыслу, к существующим возможностям конфигуратора.
-
Сделать это не прибегая к сложным процедурам выгрузки/загрузки исходников, разворачиванию Сонара или АПК непосредственно у разработчика, а также не смотря пока в сторону EDT, внедрение которого требует перестроения вообще всей цепочки работы от разработки до релиза.
Буквально несколько минут поиска информации и изучения материала привели к репозиторию https://github.com/otymko/phoenixbsl. Phoenix BSL (далее, для упрощения жизни писателю и читателю - просто Феникс) - OpenSource-проект, разрабатываемый сообществом (а точнее, самыми активными его представителями) и предназначенный для анализа кода 1С непосредственно в модулях при работе в конфигураторе. Представляет собой приложение, запускаемое параллельно с конфигуратором и проверяющее код при вызове комбинации клавиш CTRL + I. Проект основан на другом OpenSource-проекте BSL Language Server (далее BSL LS), который уже дал старт проверке кода 1С в SonarQube, подсветке и проверке кода 1С в VSCode, а также просто подсветке кода в различных текстовых редакторах.
Phoenix BSL
Не будем подробно останавливаться на процессах установки и функциональности Феникса, чтобы не переписывать readme из репозитория, тем более там всё очень подробно расписано, а среди вариантов установки доступен вариант и в msi, так что установка и настройка сводится в двум кликам, в отличие от того же Sonarqube, например. Только укажу, что Феникс не покрывает весь спектр ошибок, доступных, например в SonarQube или АПК, ввиду того, что сейчас программа не понимает какой модуль перед ней, а связи с этим не будет и проверок, завязанных на типе модуля (общий модуль, модуль объекта или модуль формы) - например нет проверки использования устаревшего свойства «ЭтаФорма». Но разработка по продукту ещё ведётся (на подходе версия 0.5), так что идеи, пожелания и жалобы можно кидать в раздел "Досад" репозитория.
А сам я остановлюсь подробнее на возможностях, помогающих работать с программой более гибко и продуктивно.
Расширяем возможности, не обновляя программу
Как уже упоминалось, Феникс создан на основе BSL LS. В состав программы уже входит BSL LS актуальной на момент сборки версии (ну или чуть более старой). Но архитектура приложения построена так, мы можем обновить BSL Server отдельно, не дожидаясь пока разработчики включать новые диагностики в программу. Что нам это даст? Новые диагностики кода и более корректная работа старых.
Откроем настройки установленного приложения. Сделать это можно через пункт "Настройки", щёлкнув ПКМ по значку в трее. Посмотреть версию BSL LS идущую в комплекте с программой можно на вкладке "BSL Language Server".
Откроем список релизов BSL LS https://github.com/1c-syntax/bsl-language-server/releases и обнаруживаем там уже версию 0.20.0 - что ж, давайте её установим. Переходим чуть ниже по странице версии, находим "Assets" - список вариантов распространения дистрибутива. И тут есть два варианта - в зависимости от вашей операционной системы и желания копаться в дополнительных настройках:
- Только для Windows - скачиваем bsl-language-server_win.zip. Распаковываем в любую удобную папку - здесь сразу порекомендую подойти к этому делу осознанно и сразу выделить каталог с нормальным названием, который не нужно будет потом долго искать - он нам потом ещё понадобится. Можете просто сделать на диске D каталог "phoenix_conf" и в него положить распакованный архив. После этого возвращаемся в настройки Phoenix и заполняем поле "Путь к BSL LS". В качестве пути указываем полный путь до .exe файла BSL LS. Обратите внимание, что в пути используются "обычный слэш", а не "обратный" как в Windows.
Нажимаете "Сохранить"
- Для Linux и Windows - скачиваем bsl-language-server-0.20.0-exec.jar. Перемещаем в удобную папку. Теперь в настройка Phoenix нам нужно указать сразу несколько настроек
- чек-бокс "Использовать BSL LS jar"
- "Путь к Java" - естественно у вас должен быть установлен java в системе. Указать его можно как через переменную среды, так и просто указать прямой путь до java.exe (используя "обычный слэш")
- "Путь к BSL LS" - полный путь до скачанного вами jar-файла (используя "обычный слэш")
Нажимаете "Сохранить"
Независимо от выбранного способа, подтверждением, что всё сделано правильно, будет номер новой версии на вкладке "BSL Language Server".
В противном случае там будет светится либо старая версия, либо "Неопределено"
Обновили сервер - получили новые диагностики.
Настраиваем диагностики
BSL Language Server (далее BSL LS) предоставляет возможность изменения настроек, заложенных разработчиками, с помощью конфигурационного файла в формате json. Сразу оговорюсь, что всё что описывается дальше, тестировалось на 1C (BSL) Community Plugin. В другом плагине BSL от "Серебряной пули" 1C (BSL) Plugin от SilverBulleters проверить, к сожалению, не могу.
В настройках программы есть пункты, касающиеся настроек BSL LS. По умолчанию Феникс осуществляет проверки по настройкам, указанным в корне программы, но их можно переопределить установив чекбокс "Свои настройки BSL LS". Путь к настройкам можно указать как относительный (относительно директории программы, как собственно и указаны "дефолтные" настройки), так и абсолютный - только не забыть изменить обратный слэш, используемый в Windows, на обычный.
Более того, можно создать разные конфигурационные файлы под разные проекты и переключаться между ними "на лету" меняя путь к конфигурационному файлу. Перезагрузка программы не требуется, потому что Феникс считывает настройки во время проверки модуля.
Про конфигурационный файл
Он представляет собой файл json c именем ".bsl-language-server.json". Базовая структура файла представлена ниже. При такой настройке проверки работают так, как заложены в BSL LS.
{
"$schema": "https://1c-syntax.github.io/bsl-language-server/configuration/schema.json",
"language": "ru",
"diagnostics": {
"computeTrigger": "onType",
"parameters": {
}
}
}
Какие диагностики включены по-умолчанию, а какие нет, их имена для конфигурационного файла, а также перечень параметров диагностик, можно посмотреть на странице BSL LS: https://1c-syntax.github.io/bsl-language-server/diagnostics/. Имейте в виду, что это диагностики BSL LS и некоторая часть из них не работает в Фениксе (вспоминаем про упомянутый выше контекст модуля). Так же учитывайте то, что перечень диагностик приведён для BSL LS последнего релиза, который может не совпадать с версией BSL LS встроенным в Феникс. Поэтому самый надёжный способ для начала работы: заменить файл указанным выше примером и, уже в процессе, по ходу выявления новых ошибок в коде, заниматься или подстройкой диагностик по параметрам или исправлениями в коде.
Сами настройки диагностик добавляются в блок "parameters". Например, мы хотим сделать что-то с ограничением длины строки. Находим её в списке диагностик (ищем просто "Ctrl+F" по ключевым словам - например, "длина"). Конфигурационный файл знает эту диагностику под именем LineLength. Для того чтобы отключить её вообще , мы можем просто указать "LineLength": false
"parameters": {
"LineLength": false
}
Либо если мы хотим просто увеличить ограничение со стандартных 120-ти символов, то можем использовать параметр "maxLineLength" и тогда в конфигурационном файле это будет выглядеть вот так:
"parameters": {
"LineLength": {
"maxLineLength": 200
}
}
Или, например диагностика "Возможна опечатка" (Typo), что актуально для процедур и функций в наших конфигурациях и на проектах, когда используется какой-либо префикс. Для неё можно указать исключения:
"parameters": {
"Typo": {
"userWordsToIgnore": "абв,abc"
}
}
Таким образом можно настроить проверки под каждый проект, в связи с актуальностью на нём тех или иных стандартов, и использовать, переключаясь между ними.
Ниже пример конфигурационного файла, увеличивающего ограничение строк до 160-ти, ругающийся только на опечатки в словах длиной более 3-х символов, с отключенной проверкой "нельзя использовать в идентификаторе одновременно латиницу и кириллицу", а также пропускающим ошибку "Длина метода"
{
"$schema": "https://1c-syntax.github.io/bsl-language-server/configuration/schema.json",
"language": "ru",
"diagnostics": {
"computeTrigger": "onType",
"parameters": {
"LineLength": {
"maxLineLength": 160
},
"Typo": {
"minWordLength": 3,
"userWordsToIgnore": "абв,abc"
},
"LatinAndCyrillicSymbolInWord": false,
"MethodSize": false
}
}
}
Кстати, этот же конфигурационный файл вы можете использовать также для диагностик в SonarQube или же в VS Code, при работе с кодом 1С или Onescript.
Заключение
По итогу мы получаем:
-
довольно простой в обращении инструмент проверки кода, позволяющий влиять на качество кода уже здесь и сейчас на проекте или отдельно взятой обработке для собственных нужд.
-
BSL LS, лежащий в основе, позволяет иметь для проекта единый настроенный файл диагностик и использовать его как в момент создания кода, так и при общей проверке конфигурации в SonarQube.
Полезные ссылки:
https://github.com/otymko/phoenixbsl - репозиторий проекта Phoenix BSL (документация, поддержка)
https://1c-syntax.github.io/bsl-language-server/features/ConfigurationFile/ - про файл конфигурирования BSL LS
https://1c-syntax.github.io/bsl-language-server/diagnostics/ - список диагностик BSL LS, а описания и параметры для конфигурационного файла.
https://t.me/bsl_language_server - telegram-канал BSL LS, а также продуктов на связанных с ним: Phoenix BSL, SonarQube
https://www.youtube.com/watch?v=by3OPvkaKco - небольшое вводное видео по Phoenix BSL с Олегом Тымко в главной роли
https://www.youtube.com/watch?v=bom-lgOq-5Y - другое небольшое вводное видео.
https://www.youtube.com/watch?v=UwCIyTktujo - немного про настройку диагностик применительно к Phoenix BSL
//infostart.ru/1c/articles/1420861/ - "Как контролировать качество внешних обработок, отчетов, правил обмена, расширений 1С и поставить это на поток" - статья Олега Тымко, где упоминается ещё ряд инструментов для упрощения работы разработчика.
