Нахождение “мертвого кода” в большом [закрытом] унаследованном приложении C++
6 ответов
Вы захотите использовать инструмент статического анализа
- StackOverflow: Какие инструменты статического анализа C ++ с открытым исходным кодом доступны?
- StackOverflow: Инструмент статического анализа кода C ++ в Windows
- Википедия: Список инструментов для статического анализа кода
Основная проблема, с которой я столкнулся, заключается в том, что вы должны быть осторожны, чтобы какие-либо библиотеки не использовались откуда-то, что вы не контролируете /имеют. Если вы удалите функцию из класса, который используется, ссылаясь на библиотеку в вашем проекте, вы можете сломать то, о чем вы не знали, использовав код.
Ничто не сравнится со знанием кода. За исключением, пожалуй, строгой обрезки по мере продвижения.
Иногда то, что выглядит как мертвый лес, используется в качестве основы для модульных тестов и т. Д., Или оно кажется живым просто потому, что устаревшие модульные тесты его проверяют, но это никогда не выполняется вне тестов.Некоторое время назад я удалил более 1000 LOC, которые поддерживали внешние переводчики моделей САПР, у нас были тесты с вызовом этих внешних переводчиков, но эти переводчики не поддерживались более 8 лет, и не было возможности, чтобы пользователь приложения, даже если бы он захотел мог когда-либо вызвать их.
Если кто-то не усердно избавляется от мертвого дерева, то обнаружится, что ваша команда хранит этот материал годами.
Думаю, вам лучше всего было бы средство покрытия. И для * nix, и для windows полно. Если у вас есть модульные тесты, это просто - если у вас низкий уровень тестового покрытия, то непокрытый код либо мертв, либо еще не протестирован (вам в любом случае нужны обе части этой информации). Если у вас нет модульных тестов, создайте свое приложение с инструментарием, предоставляемым одним из этих инструментов, запустите его через некоторые (в идеале все) пути выполнения и просмотрите отчет. Вы получаете ту же информацию, что и с модульными тестами, только для этого потребуется гораздо больше работы.
Поскольку вы используете VisualStudio, я мог бы предоставить вам пару ссылок, которые вы могли бы использовать:
Ни один из них не является бесплатным, даже не дешевым, но результат обычно бывает стоило того.
На * nix-подобных платформах gcov в сочетании с такими инструментами, как zcov или lcov - действительно отличный выбор.
Один из подходов - использовать пункт контекстного меню «Найти все ссылки» в именах классов и функций. Если на класс / функцию ссылаются только сами по себе, это почти наверняка мертвый код.
Другой подход, основанный на той же идее, - удалить (закомментировать) файлы / функции из проекта и посмотреть, какие сообщения об ошибках вы получите.
Хотя и не специально для мертвого кода, я нашел Source Navigator
довольно полезным, хотя и громоздким в настройке и немного глючным. Это было год назад на Linux (Fedora).
См. Наш Покрытие тестов SD C ++ .
Вам нужно провести много динамического тестирования, чтобы проверить код, чтобы убедиться, что вы достигли максимального покрытия. Код «не распространяется» может или не может быть мертвым; возможно, у вас просто не было тестового примера для его проверки.