Поиск неиспользуемого (иначе называемого "мертвого" ) кода в Delphi

Существуют ли какие-либо инструменты, которые могут определять, используется ли функция/метод/метод/весь класс?

Я видел инструменты, которые могут помочь хорошо осведомленному разработчику отслеживать неиспользуемые фрагменты кода (большинство из них относятся к языкам, отличным от Delphi), но большинство из них имеют крутую кривую обучения и/или требуют значительного поиска, чтобы определить, используется ли фрагмент кода или нет.

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

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

Ответ 1

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

Это происходит, я считаю, на уровне процедуры. Я не знаю способа определить это на менее грубом уровне.

Ответ 2

В этой статье обсуждается удаление неиспользуемых блоков и рассказывается о таких инструментах, как Icarus Pascal Analyzer. Этот инструмент сделает все, что вам нужно, и многое другое. Как "автоматически" удалить неиспользуемые единицы из предложения uses?

Ответ 3

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

Бесплатный (открытый исходный код) Инструмент покрытия кода для Delphi доступен здесь. После запуска проверьте наличие красных строк в отчетах, это линии, которые не были достигнуты.

Покрытие кода Delphi - это простой код Инструмент Coverage для Delphi, который создает отчеты о покрытии кода на основе подробные файлы MAP.

Для каждой единицы будет unit.html с кратким изложением охват, за которым следует источник размечена. Зеленые линии были покрыты. Красные линии не были покрыты линиями. в других строках не было сформировано кода для этого. Существует также CodeCoverage_summary.html, который обобщает охват и имеет ссылки к отчету сгенерированного блока.

Возможно, автор может добавить функцию поиска для мертвого кода в будущей версии.

Ответ 4

Вы также можете проверить наиболее часто используемый инструмент коммерческого профилирования/покрытия, AQTime от http://www.automatedqa.com

Здесь видео по функциям: http://www.automatedqa.com/products/aqtime/screencasts/coverage-profiling/

Ответ 5

Ознакомьтесь с инструментами http://www.peganza.com/, чтобы помочь с некоторыми вашими задачами.

Icarus является бесплатной и анализирует ваши предложения "uses", чтобы вы могли удалять неиспользуемые ссылки.

Pascal Analyzer - это полная версия, которая включает функциональность Icarus и массу других инструментов.

Ответ 6

Возможно, CodeHealer может помочь вам с неиспользуемым кодом

CodeHealer выполняет углубленное анализ исходного кода, поиск проблемы в следующих областях:

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

Ответ 7

Для единиц используйте анализатор Pascal. Возможно, вам придется использовать его несколько раз.

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

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

Ответ 8

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

Иногда это дает вам представление о том, почему некоторые вещи не связаны с smartlinked (например, потому что в некоторой таблице есть ссылка, к которой может быть что-то доступное при инициализации)

Конечно, Delphi - это не FPC, но когда у вас есть намеки на то, что нужно искать, нужно рассмотреть точки на полях после компиляции Delphi, чтобы увидеть, связано ли это с smartlinked или нет. Аналогичным образом, если вам интересно, почему определенный код имеет (не) интеллектуальный интерфейс, анализ небольшой примерной программы, скомпилированной для ассемблера с FPC, может сделать очевидную причину. (например, вы найдете таблицы RTTI со ссылкой на него)

Маршрут FPC позволяет систематизировать маршрут поиска кандидатов для таких тестов.