Какие инструменты использовали для качества кода (линтеры, форматтеры)

Что проверяют

Встроено ли качество кода в ваш процесс или это разовые запуски перед релизом. Для C++ интервьюер ещё смотрит, отличаете ли вы форматирование, статический анализ и проверки во время выполнения. Следом обычно спрашивают, как вы внедряли clang-tidy в старую кодовую базу с тысячами предупреждений.

Как отвечать

Разложите инструменты по слоям:

• компилятор: -Wall -Wextra -Wpedantic, в CI -Werror, сборка двумя компиляторами (GCC и Clang) ловит разные вещи;
• форматирование: clang-format с файлом .clang-format в корне на основе готового стиля (BasedOnStyle: LLVM, Google, Mozilla), в CI проверка через clang-format --dry-run --Werror;
• статический анализ: clang-tidy с наборами bugprone-*, modernize-*, performance-*, cppcoreguidelines-*. Ему нужен compile_commands.json, в CMake его даёт CMAKE_EXPORT_COMPILE_COMMANDS=ON. Дополнительно Cppcheck, PVS-Studio или SonarQube;
• динамические проверки: санитайзеры -fsanitize=address,undefined и отдельной сборкой thread в тестах, Valgrind там, где санитайзеры неудобны;
• интеграция: pre-commit хуки, проверка в CI на каждый merge request, подсказки прямо в IDE через clangd.

Про старый код скажите отдельно: проверки включаются постепенно, анализ идёт только по изменённым файлам, текущие предупреждения фиксируются как базовая линия, а новые не пропускаются. Цифры и примеры давайте из своего опыта: какую ошибку поймал анализатор, сколько предупреждений было на старте.

Где спотыкаются

Называют clang-format линтером. Он меняет только внешний вид кода и ошибок не ищет.

Забывают про санитайзеры. Для C++ они ловят то, что статический анализ не видит: выход за границы, использование после освобождения, неопределённое поведение.

Включают все проверки clang-tidy разом и получают тысячи срабатываний, которые команда начинает игнорировать. Набор проверок подбирают под проект и расширяют по мере исправлений.