Як я можу знати, які частини в коді ніколи не використовуються?

У мене є застарілий код C ++, з якого я повинен видалити невикористаний код. Проблема в тому, що база коду велика.

Як я можу дізнатися, який код ніколи не називається / ніколи не використовується?

Існує два різновиди невикористаного коду:

• локальна, тобто в деяких функціях деякі шляхи або змінні не використовуються (або використовуються, але не мають сенсу, як написані, але ніколи не читаються)
• глобальний: функції, які ніколи не викликаються, глобальні об'єкти, до яких ніколи не звертаються

Для першого виду хороший компілятор може допомогти:

• -Wunused(GCC, Clang ) слід попередити про невикористані змінні, невикористаний аналізатор Clang навіть збільшується, щоб попереджати про змінні, які ніколи не читаються (хоча вони і використовуються).
• -Wunreachable-code(старіший GCC, видалений у 2010 році ) повинен попереджати про локальні блоки, до яких ніколи не можна отримати доступ (це трапляється з ранньою віддачею або умовами, які завжди оцінюються як справжні)
• не існує жодної опції, про яку я знаю попереджати про невикористані catchблоки, оскільки компілятор, як правило, не може довести, що жоден виняток не буде викинутий.

Для другого роду це набагато складніше. Статично він вимагає цілого аналізу програми, і хоча оптимізація часу зв'язку може фактично видалити мертвий код, на практиці програма настільки сильно трансформувалася під час її виконання, що неможливо передати змістовну інформацію користувачеві.

Тому існує два підходи:

• Теоретичним є використання статичного аналізатора. Програмне забезпечення, яке вивчить весь код одразу докладно та знайде всі шляхи потоку. На практиці я не знаю жодної, яка б тут працювала.
• Прагматичним є використання евристики: використовувати інструмент покриття коду (у ланцюзі GNU це gcov. Зауважте, що під час компіляції для правильної роботи повинні бути передані конкретні прапори). Ви запускаєте інструмент покриття коду з хорошим набором різноманітних входів (ваші одиничні тести або нерегресійні тести), мертвий код обов'язково знаходиться в межах недосягнутого коду ... і ви можете почати звідси.

Якщо ви надзвичайно зацікавлені в цій темі і маєте час і схильність реально розробити інструмент самостійно, я б запропонував використовувати бібліотеки Кланг для створення такого інструменту.

1. Використовуйте бібліотеку Clang, щоб отримати AST (абстрактне синтаксичне дерево)
2. Виконайте аналіз розмітки від точок входу і далі

Оскільки Кланг розбере код для вас і виконає вирішення перевантаження, вам не доведеться мати справу з правилами мов C ++, і ви зможете зосередитись на проблемі.

Однак такий метод не може визначити невикористані віртуальні зміни, оскільки їх можна викликати стороннім кодом, про який ви не можете міркувати.

Що стосується невикористаних цілих функцій (та невикористаних глобальних змінних), GCC може фактично виконати більшу частину роботи за вас за умови, що ви використовуєте GCC та GNU ld.

Складаючи джерело, використовуйте, -ffunction-sectionsа -fdata-sectionsпотім при посиланні -Wl,--gc-sections,--print-gc-sections. Тепер лінкер перелічить всі функції, які можна було б видалити, оскільки вони ніколи не викликалися, та всі глобальні кулі, на які ніколи не було посилань.

(Звичайно, ви також можете пропустити --print-gc-sectionsчастину і дозволити лінкеру мовчки видаляти функції, але зберігати їх у джерелі.)

Примітка: це знайде лише невикористані повноцінні функції, воно нічого не зробить з мертвим кодом у функціях. Функції, викликані з мертвого коду, в живих функціях також будуть зберігатися навколо.

Деякі особливості C ++ також спричинять проблеми, зокрема:

• Віртуальні функції. Не знаючи, які підкласи існують, а які насправді інстанціюються під час виконання, ви не можете знати, які віртуальні функції потрібно існувати в кінцевій програмі. У лінкера недостатньо інформації про це, тому доведеться тримати їх навколо.
• Глобали з конструкторами та їх конструктори. Взагалі, лінкер не може знати, що конструктор для глобального не має побічних ефектів, тому він повинен запустити його. Очевидно, це означає, що і сам глобал також повинен зберігатися.

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

Додатковим застереженням є те, що якщо ви створюєте спільну бібліотеку, налаштування за замовчуванням у GCC експортують кожну функцію в спільній бібліотеці, приводячи її до "використання", що стосується посилання. Щоб виправити, що вам потрібно встановити за замовчуванням приховування символів замість експорту (використовуючи напр. -fvisibility=hidden), А потім чітко вибрати експортовані функції, які потрібно експортувати.

Добре, якщо ви використовуєте g ++, ви можете використовувати цей прапор -Wunused

Відповідно до документації:

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

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Редагувати : Ось інший корисний прапор -Wunreachable-code Відповідно до документації:

Цей параметр призначений для попередження, коли компілятор виявить, що принаймні цілий рядок вихідного коду ніколи не буде виконаний, оскільки якась умова ніколи не виконується або тому, що це після процедури, яка ніколи не повертається.

Оновлення : я знайшов аналогічну тему Виявлення мертвого коду у застарілому проекті C / C ++

Я думаю, ви шукаєте інструмент для покриття коду . Інструмент покриття коду проаналізує ваш код під час його запуску, і він дозволить вам знати, які рядки коду виконувались і скільки разів, а також які не були.

Ви можете спробувати надати шанс цього інструменту покриття відкритого коду: TestCocoon - інструмент покриття коду для C / C ++ та C #.

Справжня відповідь тут така: Ви ніколи не можете точно знати точно.

Принаймні, у нетривіальних випадках ви не можете бути впевнені, що ви все це здобули. Розглянемо наступне зі статті Вікіпедії про недосяжний код :

double x = sqrt(2);
if (x > 5)
{
  doStuff();
}

Як правильно зазначає Вікіпедія, розумний компілятор, можливо, зможе зловити щось подібне. Але врахуйте модифікацію:

int y;
cin >> y;
double x = sqrt((double)y);

if (x != 0 && x < 1)
{
  doStuff();
}

Чи вловить це компілятор? Можливо. Але для цього потрібно буде більше, ніж sqrtпротистояти постійному скалярному значенню. Доведеться зрозуміти, що (double)yзавжди буде цілим числом (легким), а потім зрозуміти математичний діапазон sqrtдля набору цілих чисел (важко). Дуже складний компілятор може зробити це для sqrtфункції, або для кожної функції в math.h , або для будь-якої функції з фіксованим входом, домен якої може визначити. Це стає дуже, дуже складним, а складність в основному безмежна. Ви можете продовжувати додавати шари вишуканості у ваш компілятор, але завжди знайдеться спосіб прокрастись у якийсь код, який буде недоступний для будь-якого набору входів.

А потім є набори введення, які просто ніколи не вводяться. Вхід, який би не мав сенсу в реальному житті, або заблокований логікою перевірки в іншому місці. Компілятор не може знати про них.

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

Єдине справжнє рішення - IMHO - бути максимально пильним, використовувати автоматику, яка є у вашому розпорядженні, рефактор, де ви можете, і постійно шукати шляхи вдосконалення свого коду. Звичайно, це все-таки добре зробити.

Я сам не користувався цим, але cppcheck , стверджує, що знаходить невикористані функції. Це, мабуть, не вирішить повну проблему, але це може бути початком.

Ви можете спробувати використовувати PC-lint / FlexeLint від Gimple Software . Це претендує на

знаходити невикористані макроси, typedef, класи, члени, декларації тощо у всьому проекті

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

Мій звичайний підхід до пошуку невикористаних речей - це

1. переконайтесь, що система збірки правильно обробляє відстеження залежності
2. налаштуйте другий монітор із повним екраном термінального вікна, виконуючи повторні складання та показуючи перший скріншот виводу. watch "make 2>&1"прагне зробити трюк на Unix.
3. запустіть операцію пошуку та заміни у всьому дереві джерела, додавши "//?" на початку кожного рядка
4. виправити першу помилку, позначену компілятором, видаливши "//?" у відповідних рядках.
5. Повторюйте, поки не залишиться помилок.

Це дещо тривалий процес, але він дає хороші результати.

Позначте стільки загальнодоступних функцій і змінних як приватні або захищені, не викликаючи помилок компіляції, виконуючи це, намагайтеся також рефакторировать код. Роблячи функції приватними та певною мірою захищеними, ви зменшили область пошуку, оскільки приватні функції можна викликати лише з одного класу (якщо немає дурних макро чи інших хитрощів, щоб обійти обмеження доступу, і якщо це так, я б рекомендував вам знайти нову роботу). Набагато простіше визначити, що вам не потрібна приватна функція, оскільки лише клас, над яким ви зараз працюєте, може викликати цю функцію. Цей спосіб простіший, якщо у вашій кодовій базі є невеликі класи та вони зв'язані слабко. Якщо у вашій кодовій базі немає малих класів або у вас дуже щільне з'єднання, я пропоную їх попередньо очистити.

Далі буде позначати всі публічні функції, що залишилися, і робити графік виклику, щоб з'ясувати взаємозв'язок між класами. З цього дерева спробуйте з’ясувати, яка частина гілки виглядає, як її можна обрізати.

Перевага цього методу полягає в тому, що ви можете робити це на основі модулів, тому легко тримати проходження свого тесту без великого періоду часу, коли у вас зламана база коду.

Якщо ви працюєте в Linux, можливо, ви захочете заглянути callgrindінструмент аналізу програм C / C ++, який є частиною valgrindнабору, який також містить інструменти, які перевіряють наявність витоків пам'яті та інших помилок пам'яті (які ви також повинні використовувати). Він аналізує запущений примірник вашої програми та виробляє дані про її графік викликів та про витрати на ефективність вузлів на графіку викликів. Зазвичай він використовується для аналізу продуктивності, але він також створює графік викликів для ваших програм, так що ви можете бачити, як називаються функції, а також їх дзвінки.

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

Я справді не використовував жодного інструменту, який би робив таку дію ... Але, наскільки я бачив у всіх відповідях, ніхто ніколи не говорив, що ця проблема є непорушною.

Що я маю на увазі під цим? Ця проблема не може бути вирішена жодним алгоритмом, коли-небудь на комп'ютері. Ця теорема (що такого алгоритму не існує) є наслідком проблеми зупинки Тьюрінга.

Усі інструменти, які ви будете використовувати, - це не алгоритми, а евристика (тобто не точні алгоритми). Вони не дадуть вам точно весь код, який не використовується.

Одним із способів є використання налагоджувача та функції компілятора для усунення невикористаного машинного коду під час компіляції.

Після усунення деякого машинного коду відладчик не дозволить вам поставити breakpojnt у відповідний рядок вихідного коду. Таким чином, ви ставите точки прориву скрізь і запускаєте програму та перевіряєте точки прориву - ті, які перебувають у стані "жодного коду не завантажено для цього джерела", відповідають виключеному коду - або цей код ніколи не викликається, або він був накреслений, і ви повинні виконати деякий мінімум аналіз, щоб знайти, хто з цих двох стався.

Принаймні, так це працює у Visual Studio, і я думаю, що інші набори інструментів також можуть це зробити.

Це багато роботи, але я думаю, що швидше, ніж вручну аналізувати весь код.

CppDepend - комерційний інструмент, який може виявляти невикористані типи, методи та поля та робити багато іншого. Він доступний для Windows та Linux (але на даний момент не має 64-розрядної підтримки) та проходить 2-тижневу пробну версію.

Відмова: Я не працюю там, але я маю ліцензію на цей інструмент (як і NDepend , яка є більш потужною альтернативою коду .NET).

Для тих, хто цікавиться, ось приклад вбудованого (настроюваного) правила виявлення мертвих методів, написаного на CQLinq :

// <Name>Potentially dead Methods</Name>
warnif count > 0
// Filter procedure for methods that should'nt be considered as dead
let canMethodBeConsideredAsDeadProc = new Func<IMethod, bool>(
    m => !m.IsPublic &&       // Public methods might be used by client applications of your Projects.
         !m.IsEntryPoint &&            // Main() method is not used by-design.
         !m.IsClassConstructor &&      
         !m.IsVirtual &&               // Only check for non virtual method that are not seen as used in IL.
         !(m.IsConstructor &&          // Don't take account of protected ctor that might be call by a derived ctors.
           m.IsProtected) &&
         !m.IsGeneratedByCompiler
)

// Get methods unused
let methodsUnused = 
   from m in JustMyCode.Methods where 
   m.NbMethodsCallingMe == 0 && 
   canMethodBeConsideredAsDeadProc(m)
   select m

// Dead methods = methods used only by unused methods (recursive)
let deadMethodsMetric = methodsUnused.FillIterative(
   methods => // Unique loop, just to let a chance to build the hashset.
              from o in new[] { new object() }
              // Use a hashet to make Intersect calls much faster!
              let hashset = methods.ToHashSet()
              from m in codeBase.Application.Methods.UsedByAny(methods).Except(methods)
              where canMethodBeConsideredAsDeadProc(m) &&
                    // Select methods called only by methods already considered as dead
                    hashset.Intersect(m.MethodsCallingMe).Count() == m.NbMethodsCallingMe
              select m)

from m in JustMyCode.Methods.Intersect(deadMethodsMetric.DefinitionDomain)
select new { m, m.MethodsCallingMe, depth = deadMethodsMetric[m] }

Це залежить від платформи, яку ви використовуєте для створення своєї програми.

Наприклад, якщо ви використовуєте Visual Studio, ви можете використовувати такий інструмент, як .NET ANTS Profiler, який здатний проаналізувати і профайлювати ваш код. Таким чином, ви повинні швидко знати, яка частина вашого коду фактично використовується. Eclipse також має еквівалентні плагіни.

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

Для кожної основної функції ви можете простежити її використання, а через кілька днів / тиждень просто отримати цей файл журналу та ознайомитися з ним.

Я не думаю, що це можна зробити автоматично.

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

Може бути дуже складним і дорогоцінним інструментом статичного аналізу, таким як компілятор Coverity або LLVM, може допомогти.

Але я не впевнений, і я вважаю за краще ручний перегляд коду.

ОНОВЛЕНО

Ну .. тільки видалення невикористаних змінних, невикористаних функцій не важко, хоча.

ОНОВЛЕНО

Прочитавши інші відповіді та коментарі, я переконаний, що цього зробити не можна.

Ви повинні знати код, щоб мати змістовну міру покриття коду, і якщо ви знаєте, що багато вручну редагування буде швидше, ніж підготовка / запуск / перегляд результатів покриття.

Сьогодні у мене був друг, який задав мені це запитання, і я оглянув деякі перспективні розробки Clang, наприклад, ASTMatcher s та статичний аналізатор, які могли б мати достатню видимість в роботі під час компіляції для визначення розділів мертвого коду, але тоді я знайшов це:

https://blog.flameeyes.eu/2008/01/today-how-to-identify-unused-exported-functions-and-variables

Це майже повний опис того, як використовувати декілька прапорів GCC, які, здавалося б, розроблені з метою ідентифікації невизначених символів!

Загальна проблема, якщо якась функція буде викликана, - NP-Complete. Ви не можете заздалегідь дізнатися, чи буде викликана якась функція, оскільки ви не знатимете, чи машина колись зупиниться. Ви можете отримати, якщо є якийсь шлях (статично), який йде від main () до функції, яку ви написали, але це не гарантує вас, що коли-небудь буде викликано.

Добре, якщо ви використовуєте g ++, ви можете використовувати цей прапор -Wunused

Відповідно до документації:

Warn whenever a variable is unused aside from its declaration, whenever a function is declared static but never defined, whenever a label is declared but not used, and whenever a statement computes a result that is explicitly not used.

http://docs.freebsd.org/info/gcc/gcc.info.Warning_Options.html

Редагувати: Ось інший корисний прапор - Недоступний код Відповідно до документації:

This option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.