Почему SonarQube ругается на ваш код и как писать «чистый» код в 1С?

← На главную

При использовании инструментов статического анализа кода, таких как SonarQube или АПК, многие разработчики сталкиваются с критикой, которая на первый взгляд кажется избыточной: требования к пробелам в комментариях или жалобы на «слишком сложные условия». Давайте разберем, почему эти инструменты важны, какую пользу они приносят и как правильно оптимизировать код, чтобы он соответствовал современным стандартам разработки.

Понимаем суть «говнокода» и когнитивную сложность

Когда система анализа выдает ошибку «Слишком сложное условие в Если», она не пытается сказать, что код работает медленно. Проблема заключается в когнитивной сложности. Программист, который будет читать ваш код через полгода, должен мгновенно понять логику, не тратя время на разбор многоэтажных конструкций.

Рассмотрим классический пример «сложного» условия, которое часто встречается в коде:


Если ТипЗнч(ДокОбъект) = Тип("ДокументОбъект.ПриходныйКассовыйОрдер")
    Или ТипЗнч(ДокОбъект) = Тип("ДокументОбъект.ПоступлениеБезналичныхДС")
    Или ТипЗнч(ДокОбъект) = Тип("ДокументОбъект.ВзаимозачетДенежныхСредств") Тогда
    Возврат Истина;
КонецЕсли;

С точки зрения анализатора, это условие трудночитаемо. Чтобы сделать его «чистым», нам нужно применить декомпозицию.

Способ 1: использование списка значений для проверки типов

Если вам нужно проверить принадлежность объекта к группе типов, не обязательно городить сложные логические «ИЛИ». Использование СписокЗначений делает код декларативным и расширяемым.


ТипыДляПроверки = Новый СписокЗначений();
ТипыДляПроверки.Добавить(Тип("ДокументОбъект.ПриходныйКассовыйОрдер"));
ТипыДляПроверки.Добавить(Тип("ДокументОбъект.ПоступлениеБезналичныхДС"));
ТипыДляПроверки.Добавить(Тип("ДокументОбъект.ВзаимозачетДенежныхСредств"));

Если ТипыДляПроверки.НайтиПоЗначению(ТипЗнч(ДокОбъект)) <> Неопределено Тогда
    Возврат Истина;
КонецЕсли;

Такой код гораздо легче поддерживать: если завтра потребуется добавить новый тип документа, вы просто добавляете одну строку в список, не трогая логику условия.

Способ 2: использование поясняющих переменных

Если условие не связано с типами, используйте промежуточные переменные с «говорящими» именами. Это помогает читателю сразу понять суть операции без анализа внутренностей функции.


ТипДокумента = ТипЗнч(ДокОбъект);

ЭтоПриходДенег = (ТипДокумента = Тип("ДокументОбъект.ПриходныйКассовыйОрдер"))
    Или (ТипДокумента = Тип("ДокументОбъект.ПоступлениеБезналичныхДС"));

Если ЭтоПриходДенег Тогда
    // Ваша логика
КонецЕсли;

Здесь переменная ЭтоПриходДенег выступает в роли документации. Название функции или переменной должно отвечать на вопрос «что делает этот код?», а не «как он это делает».

Почему важны стандарты оформления (пробелы и комментарии)

Многие недоумевают, зачем SonarQube требует пробел после // в комментариях. Это требование — часть стандарта разработки 1С. Основная причина — визуальная гигиена.

Отсутствие пробела делает код «зажатым».
Единый стандарт (пробел после знаков комментария) принят во всем мире программирования (даже редакторы кода типа VS Code ставят его автоматически).
При массовой проверке кода десятками разработчиков следование единому стилю избавляет команду от ненужных споров при код-ревью.

Советы по внедрению анализа в процесс разработки

Не воспринимайте это как наказание: Статический анализ — это гигиена. Он нужен, чтобы код в проекте выглядел так, будто его писал один человек.
Используйте АПК для стандартов 1С: Инструмент АПК от фирмы 1С глубже знает специфику метаданных (роли, права, формы), используйте его для проверки соответствия стандартам фирмы.
Используйте SonarQube для командной работы: Если в команде много людей, SonarQube поможет быстро отслеживать «кодовый долг» и не допускать деградации качества продукта.
Рефакторьте постепенно: Не обязательно переписывать весь старый код сразу. Начните применять правила «чистого кода» к каждому новому модулю или задаче, которую вы берете в работу.

Помните: краткость — это хорошо, но читаемость — лучше. Иногда увеличение количества строк кода за счет разбиения логики на простые блоки значительно ускоряет работу всей команды, так как коллеги тратят меньше времени на попытки осознать, что именно хотел сказать автор.