Статический анализ кода в CI: clang-tidy, cppcheck

Введение

Тесты проверяют поведение кода во время выполнения — статический анализ исследует исходный код без его реального запуска, выявляя потенциальные ошибки, проблемы стиля, и небезопасные паттерны через анализ самого текста и структуры кода. В статье разберём интеграцию популярных инструментов статического анализа C++ (clang-tidy, cppcheck) в CI-пайплайн.

Концепция

clang-tidy — инструмент на основе инфраструктуры Clang, проверяющий код против настраиваемого набора «проверок» (checks), охватывающих стиль кода, потенциальные ошибки (использование уже перемещённого объекта, утечки ресурсов), и современные практики C++ (предложение замены устаревших конструкций на более современные эквиваленты). cppcheck — независимый, более узкоспециализированный на обнаружении реальных ошибок (а не стиля) статический анализатор, дополняющий, а не заменяющий clang-tidy за счёт несколько отличного набора обнаруживаемых проблем. Интеграция в CI означает, что эти проверки выполняются автоматически при каждом изменении, а не только при случайном, нерегулярном ручном запуске разработчиком.

Пример кода

# Запуск clang-tidy в CI с конфигурацией через .clang-tidy файл в репозитории
- name: Установка clang-tidy
  run: sudo apt-get install -y clang-tidy

- name: Запуск clang-tidy
  run: |
    cmake -B build -S . -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
    run-clang-tidy -p build src/*.cpp

# .clang-tidy — конфигурация проверок (в корне репозитория, версионируется вместе с кодом)
Checks: >
  -*,
  bugprone-*,
  modernize-*,
  performance-*,
  -modernize-use-trailing-return-type
WarningsAsErrors: 'bugprone-*'
# WarningsAsErrors превращает указанные предупреждения в ОШИБКИ, прерывающие CI —
# тогда как остальные проверки остаются просто информационными предупреждениями

# Запуск cppcheck в дополнение к clang-tidy
- name: Установка и запуск cppcheck
  run: |
    sudo apt-get install -y cppcheck
    cppcheck --enable=warning,performance --error-exitcode=1 src/
    # --error-exitcode=1 — ненулевой код возврата при обнаружении проблем,
    # что автоматически делает CI-задачу неуспешной, прерывая дальнейший процесс

Пояснения к коду

-DCMAKE_EXPORT_COMPILE_COMMANDS=ON генерирует файл compile_commands.json, содержащий точные команды компиляции для каждого файла проекта — clang-tidy использует эту информацию для корректного анализа кода с учётом реальных флагов компиляции, путей включения заголовков, и стандарта C++, используемых при реальной сборке проекта, без которой анализ мог бы дать неточные или вводящие в заблуждение результаты, не отражающие реальную конфигурацию сборки. .clang-tidy конфигурация с WarningsAsErrors: 'bugprone-*' показывает практичную, дифференцированную стратегию — проверки категории «bugprone» (потенциально реальные ошибки) превращаются в обязательные, прерывающие CI ошибки, тогда как остальные, менее критичные проверки (стиль, предложения модернизации) остаются информационными предупреждениями, не блокирующими процесс, что позволяет постепенно улучшать код без необходимости немедленно устранять абсолютно все, даже наименее критичные замечания статического анализатора.

Подводные камни

Включение статического анализа в CI как обязательного, блокирующего шага сразу для уже большого, существующего проекта без предварительной оценки объёма уже накопленных предупреждений — запуск статического анализатора на впервые проверяемом, давно существующем проекте часто выявляет огромное количество предупреждений, накопившихся за время разработки без такой проверки, и попытка немедленно сделать все эти предупреждения блокирующими ошибками CI может полностью остановить разработку до их массового устранения; практичный подход — постепенное включение, начиная с наиболее критичных категорий проверок (как bugprone-* в примере) как блокирующих, оставляя остальные информационными до постепенного устранения в рабочем порядке.
Игнорирование различия в скорости работы между разными наборами проверок — некоторые категории проверок clang-tidy (особенно более продвинутые, основанные на глубоком анализе потока данных) значительно медленнее простых, синтаксических проверок, и для больших проектов включение всех возможных проверок без разбора может существенно замедлить общее время выполнения CI; набор включённых проверок стоит выбирать с учётом баланса между полнотой анализа и приемлемым временем выполнения.
Использование clang-tidy без актуального файла compile_commands.json, отражающего реальную конфигурацию сборки (флаги компиляции, определённые макросы, используемый стандарт C++) — без этой информации анализ может пропустить реальные проблемы или, наоборот, выдать ложные срабатывания, основанные на неверных предположениях о конфигурации сборки, отличной от реально используемой.
Восприятие «чистого» прохождения статического анализа как полной гарантии отсутствия ошибок в коде — статический анализ обнаруживает определённые категории проблем (типичные паттерны ошибок, известные антипаттерны), но принципиально не может обнаружить все возможные логические, содержательные ошибки в коде (статический анализатор не понимает бизнес-логику и предполагаемое поведение приложения) — статический анализ дополняет, но не заменяет тестирование и человеческий code review как взаимодополняющие, а не взаимоисключающие практики обеспечения качества кода.