В настоящее время я работаю над большим и старым С++-приложением, в котором много разработчиков передо мной. В проекте есть много "мертвого кода", классов и функций, которые больше не используются кем-либо.
Какие инструменты доступны для С++ для анализа большой базы кода для обнаружения и реорганизации мертвого кода? Примечание. Я не говорю об инструментах для тестирования, таких как gcov.
Как вы нашли мертвый код в своем проекте?
Вам понадобится инструмент статического анализа
Основная проблема, с которой я столкнулся, заключается в том, что вы должны быть осторожны, чтобы какие-либо библиотеки не использовались откуда-то, что вы не контролируете/не имеете. Если вы удаляете функцию из класса, который используется для ссылки на библиотеку в вашем проекте, вы можете сломать то, что вы не знали, используя код.
Вы можете использовать Cppcheck для этой цели:
$ cppcheck --enable=unusedFunction .
Checking 2380153.c...
1/2 files checked 0% done
Checking main.c...
2/2 files checked 0% done
[2380153.c:1]: (style) The function '2380153' is never used.
Caolán McNamara callcatcher очень эффективно используется в проекте LibreOffice (~ 6 MLOC), чтобы найти мертвый код.
Один из подходов - использовать пункт контекстного меню "Найти все ссылки" в именах классов и функций. Если класс/функция упоминается только по себе, это почти наверняка мертвый код.
Другой подход, основанный на той же идее, состоит в том, чтобы удалить (закомментировать) файлы/функции из проекта и посмотреть, какие сообщения об ошибках вы получите.
Я думаю, что ваш лучший выбор, вероятно, будет инструментом покрытия. Есть много для * nix и windows. Если у вас есть модульные тесты, легко - если у вас низкий уровень охвата тестированием, то непокрытый код либо мертв, либо еще не проверен (вы хотите, чтобы оба фрагмента этой информации в любом случае). Если у вас нет модульных тестов, создайте приложение с помощью инструментария, предоставляемого одним из этих инструментов, запустите его через некоторые (все должно быть идеально) пути выполнения и просмотрите отчет. Вы получаете ту же информацию, что и с модульными тестами, для этого потребуется гораздо больше работы.
Поскольку вы используете VisualStudio, я могу предоставить вам пару ссылок, которые вы могли бы использовать:
Ни один из них не является бесплатным, даже не дешевым, но результат обычно стоит того.
На * nix-подобных платформах gcov в сочетании с такими инструментами, как zcov или lcov - действительно отличный выбор.
Ничто не сравнится с кодом. За исключением, возможно, жесткой обрезки, как один идет.
Иногда то, что выглядит как мертвое дерево, используется в качестве подкладок для модульных тестов и т.д., или оно, кажется, живое просто потому, что его используют устаревшие юнит-тесты, но он никогда не используется вне тестов. Некоторое время назад я удалил более 1000 LOC, которые поддерживали внешних переводчиков модели CAD, у нас были тесты с привлечением этих внешних переводчиков, но эти переводчики не поддерживались в течение 8+ лет, и не было никакого способа, чтобы пользователь приложения, даже если они хотели могут когда-либо ссылаться на них.
Если кто-то не хочет избавиться от мертвой древесины, вы найдете свою команду в течение многих лет.
Хотя это не специально для мертвого кода, я нашел Source Navigator
довольно полезно, хотя и громоздко настраивать и немного багги. Это было год назад в Linux (Fedora).
Смотрите наш SD С++ Test Coverage.
Вам нужно сделать много динамического тестирования, чтобы реализовать код, чтобы убедиться, что вы достигли максимального уровня охвата. Кодекс "не распространяется" может быть или не быть мертвым; возможно, у вас просто нет тестового примера для его осуществления.