Перейти к содержанию

BSL256 - Опечатка

← Все правила

Кратко

Опечатка

Идентификаторы

Поле Значение
Код правила BSL256
Совместимый псевдоним Typo
Серьёзность INFORMATION
Без конфигурации Да
BSLLS JSON, режим ON без переопределений Да
Флаг реестра implemented Да
Теги convention

Флаг implemented отражает реестр и не подтверждает проверенное совпадение с BSLLS.

Поведение

  • Публичный идентификатор BSL256 и псевдоним Typo стабильны.
  • Правило сообщает о случаях, описанных на этой странице.
  • Подавления и проектная конфигурация применяются до публикации результата.
  • Для выполнения правила не требуется внешний анализатор или сетевой доступ.

Настройка и подавление

Код BSL### - основной стабильный идентификатор. Совместимый псевдоним принимается в select, ignore и совместимых блоковых комментариях.

[tool.onec-hbk-bsl]
select = ["BSL256"]
ignore = ["Typo"]

Все три семейства подавлений работают для текущей строки и диапазона. Если открывающий комментарий стоит после кода, он действует только на эту строку. Используйте любой один вариант:

  • noqa:
Значение = "пример";  // noqa: BSL256
  • bsl-disable (совместимый вариант):
Значение = "пример";  // bsl-disable: BSL256
  • совместимый BSLLS-вариант:
Значение = "пример";  // BSLLS:Typo-off

Если тот же открывающий комментарий стоит на отдельной строке, он начинает диапазон. Закройте его парным маркером того же семейства:

// noqa: BSL256
// код без этой диагностики
// noqa-enable: BSL256

// bsl-disable: BSL256
// код без этой диагностики
// bsl-enable: BSL256

// BSLLS:Typo-off
// код без этой диагностики
// BSLLS:Typo-on

Чтобы отключить правило до конца файла, не добавляйте закрывающий noqa-enable, bsl-enable или BSLLS:…-on.

Открывающий и закрывающий маркеры должны принадлежать одному семейству.

Описание диагностики

Проверка орфографических ошибок осуществляется с помощью LanguageTool. Проверяемые строки разбиваются по camelCase и проверяются на соответствие во встроенном словаре.

Кэш

Диагностика использует персистентный кэш на диске (EhCache) для хранения информации об уже проверенных словах. Путь к каталогу кэша настраивается с помощью свойств app.cache.basePath и app.cache.fullPath в конфигурации приложения.

По умолчанию в приложении установлено:

app.cache.basePath=${user.home}
app.cache.fullPath=

Это означает, что: - Кэш будет создаваться в каталоге пользователя (${user.home}/.bsl-language-server/cache/<hash>/) - <hash> — MD5-хэш абсолютного пути к текущей рабочей директории, что обеспечивает изоляцию кэша для разных workspace - Кэш не создается в рабочей директории проекта, не захламляя git-репозитории

Для переопределения пути к кэшу можно использовать: - app.cache.fullPath — полный путь к каталогу кэша (если задан, используется напрямую) - app.cache.basePath — базовый путь для автоматического вычисления (по умолчанию ${user.home})

Пример переопределения:

# Задать явный путь к кэшу
app.cache.fullPath=/custom/cache/location

# Или изменить только базовый путь
app.cache.basePath=/opt/bsl-ls
# Результат: /opt/bsl-ls/.bsl-language-server/cache/<hash>/

Рекомендации для CI:

Важно: С новой версией кэш по умолчанию хранится в каталоге пользователя с хэшем workspace. Для CI рекомендуется явно задать app.cache.fullPath для упрощения кэширования между сборками.

  • GitHub Actions
  • Задайте явный путь к кэшу в переменных окружения или конфигурации
  • Используйте actions/cache для сохранения каталога между прогоном сборок и тестов
- name: Cache BSL LS Typo
  uses: actions/cache@v3
  with:
    path: .bsl-ls-cache
    key: ${{ runner.os }}-bsl-typo-${{ hashFiles('**/*.bsl') }}
    restore-keys: |
      ${{ runner.os }}-bsl-typo-
  • GitLab CI

  • В .gitlab-ci.yml используйте секцию cache:

    variables:
  APP_CACHE_FULLPATH: ".bsl-ls-cache"

cache:
  key: "bsl-ls-typo-cache"
  paths:
    - .bsl-ls-cache/
  policy: pull-push

  • При необходимости задайте уникальный key для разных веток/раннеров.

  • Jenkins

  • Задайте переменную окружения APP_CACHE_FULLPATH для явного пути к кэшу
  • В pipeline можно сохранить каталог кэша между сборками несколькими способами:
    • Использовать stash/unstash для передачи данных между этапами в одной сборке.
    • Использовать плагин Workspace Cleanup и настроить сохранение workspace на агенте (если агенты постоянные) или архивировать артефакт с помощью archiveArtifacts и скачивать при следующих сборках.
    • Для Jenkins при использовании динамических агентов (например, Kubernetes) рекомендуется сохранять кэш в сетевом хранилище или в объектном хранилище (S3) и восстанавливать его в начале job.

Общие рекомендации: - Для CI-окружений рекомендуется явно задать app.cache.fullPath (например, .bsl-ls-cache в workspace проекта) для упрощения кэширования - Убедитесь, что путь к кэшу доступен процессу сборки и имеет достаточные права.

Источники