Phoenix BSL: правим ошибки "не отходя от кассы" - Разработки 1С:Предприятие

Phoenix BSL: правим ошибки «не отходя от кассы»

Простой инструмент проверки кода без длинных мануалов и многочасовых конвейеров.

Описание
Подробнее

Описание

Введение

Во время разработки не всегда удаётся следить за качеством кода и соответствием его стандартам. Да, есть АПК и 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 Language Server (далее BSL LS) предоставляет возможность изменения настроек, заложенных разработчиками, с помощью конфигурационного файла в формате json. Как уже упоминалось, Феникс создан на основе BSL LS, поэтому мы можем воспользоваться этой возможностью. Сразу оговорюсь, что всё что описывается дальше, тестировалось на 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". Например, мы хотим сделать что-то с ограничением длины строки. Находим её в списке диагностик. Конфигурационный файл знает эту диагностику под именем 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

//sale.itcity.ru/1c/articles/1420861/ — "Как контролировать качество внешних обработок, отчетов, правил обмена, расширений 1С и поставить это на поток" — статья Олега Тымко, где упоминается ещё ряд инструментов для упрощения работы разработчика.

Каталог решений - Phoenix BSL: правим ошибки «не отходя от кассы»