Обнаружение мертвого кода в устаревшем проекте C / C++

Инструмент покрытия Яблочко поможет. Однако это не бесплатно.

Для этого вы можете использовать инструмент анализа покрытия кода и искать неиспользуемые места в вашем коде.

Популярным инструментом для набора инструментов gcc является gcov вместе с графическим интерфейсом lcov (http://ltp.sourceforge.net/coverage/lcov.php).

Если вы используете gcc, вы можете скомпилировать с поддержкой gcov, которая включается флагом --coverage. Затем запустите приложение или набор тестов с этой сборкой с поддержкой gcov.

Обычно gcc генерирует некоторые дополнительные файлы во время компиляции, а приложение также генерирует некоторые данные о покрытии во время работы. Вы должны собрать все это (файлы .gcdo и .gcda). Я не буду вдаваться в подробности здесь, но вам, вероятно, потребуется установить две переменные среды для разумного сбора данных о покрытии: GCOV_PREFIX и GCOV_PREFIX_STRIP ...

После запуска вы можете собрать все данные о покрытии и запустить их с помощью lcov toolsuite. Слияние всех файлов покрытия из разных тестовых прогонов также возможно, хотя и с некоторыми трудностями.

Как бы то ни было, в итоге вы получаете хороший набор веб-страниц, показывающих некоторую информацию о покрытии, указывающих на фрагменты кода, которые не имеют покрытия и, следовательно, не использовались.

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

Ваш подход зависит от доступности (автоматизированных) тестов. Если у вас есть набор тестов, который, как вы доверяете, охватывает достаточный объем функциональности, вы можете использовать анализ покрытия, как уже предлагалось в предыдущих ответах.

Если вам не повезло, вы можете изучить инструменты анализа исходного кода, такие как SciTools 'Поймите, что может помочь вам проанализировать ваш код, используя множество встроенных аналитических отчетов. Мой опыт работы с этим инструментом начался 2 года назад, поэтому я не могу дать вам подробностей, но что я помню, так это то, что у них была впечатляющая поддержка с очень быстрым временем обработки исправлений ошибок и ответами на вопросы.

Я нашел страницу на статический анализ исходного кода, где также перечислены многие другие инструменты.

Если и это вам не поможет, и вы особенно заинтересованы в обнаружении мертвого кода, связанного с препроцессором, я бы порекомендовал вам опубликовать более подробную информацию о коде. Например, если это в основном связано с различными комбинациями настроек #ifdef, вы можете написать сценарии для определения (комбинаций) настроек и выяснения, какие комбинации на самом деле никогда не создаются и т. д.

Скомпилируйте его под gcc с -Wunreachable-code.

Я думаю, что чем более свежая версия будет, тем лучшие результаты вы получите, но я могу ошибаться, полагая, что это то, над чем они активно работали. Обратите внимание, что это анализ потока, но я не верю, что он говорит вам о «коде», который уже мертв к тому моменту, когда он покидает препроцессор, потому что он никогда не анализируется компилятором. Он также не обнаружит, например, экспортируемые функции, которые никогда не вызываются, или специальный код обработки случая, который оказывается невозможным, потому что ничто никогда не вызывает функцию с этим параметром - для этого требуется покрытие кода (и запускайте функциональные тесты, а не модульные тесты. предполагаемый, чтобы иметь 100% покрытие кода и, следовательно, выполнять пути кода, которые «мертвы» для приложения). Тем не менее, учитывая эти ограничения, это простой способ начать поиск наиболее сложных подпрограмм в кодовой базе.

В этой рекомендации CERT перечислены некоторые другие инструменты для обнаружения статического мертвого кода.

И Mozilla, и Открытый офис имеют собственные решения.

g ++ 4.01 -Wunreachable-code предупреждает о недоступности кода внутри функции, но не предупреждает о неиспользуемых функциях.

int foo() { 
    return 21; // point a
}

int bar() {
  int a = 7;
  return a;
  a += 9;  // point b
  return a;
}

int main(int, char **) {
    return bar();
}

g ++ 4.01 выдаст предупреждение о точке b, но ничего не скажет о foo () (точка a), даже если она недоступна в этом файле. Такое поведение является правильным, хотя и разочаровывающим, поскольку компилятор не может знать, что функция foo () не объявлена ​​как extern в каком-то другом модуле компиляции и не вызывается оттуда; только компоновщик может быть уверен.

Подобный анализ мертвого кода требует глобального анализа всего вашего проекта. Вы не можете получить эту информацию, анализируя единицы перевода по отдельности (ну, вы можете обнаружить мертвые объекты, если они полностью находятся в одной единице перевода, но я не думаю, что это то, что вы действительно ищете).

Мы использовали наш DMS Software Reengineering Toolkit, чтобы реализовать именно это для кода Java, анализируя все задействованные единицы компиляции одновременно, создавая таблицы символов для всего и отслеживая все ссылки. Определение верхнего уровня без ссылок и утверждения о том, что оно является внешним элементом API, мертво. Этот инструмент также автоматически удаляет мертвый код, и в конце вы можете выбрать то, что хотите: отчет о мертвых объектах или код, лишенный этих объектов.

DMS также анализирует C++ на различных диалектах (EDIT, февраль 2014 г .: включая версии C++ 14 для MS и GCC [ИЗМЕНИТЬ ноябрь 2017 г .: теперь C++ 17]) и строит все необходимые таблицы символов. Отследить мертвые ссылки с этого момента будет просто. DMS также можно использовать для их удаления. См. http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Только для кода C и при условии, что исходный код всего проекта доступен, запустите анализ с помощью инструмента с открытым исходным кодом Фрама-С. Любой оператор программы, который отображается красным в графическом интерфейсе пользователя, является мертвый код.

Если у вас есть проблемы с "мертвым кодом", вас также может заинтересовать удаление "запасного кода", кода, который выполняется, но не способствовать конечному результату. Это требует от вас предоставления точное моделирование функций ввода / вывода (вы бы не хотели чтобы удалить вычисление, которое кажется "лишним", но который используется в качестве аргумента для printf). Frama-C имеет возможность указать запасной код.