Протягом довгого часу працюючи над додатком для iPhone, я зрозумів, що мій код досить брудний, що містить декілька #import та методів, які взагалі не викликаються чи корисні.
Мені хотілося б знати, чи є якась директива компілятора чи спосіб виявити ці марні рядки коду. Чи має Xcode якийсь інструмент для виявлення цього?
Відповіді:
Xcode дозволяє (не) перевіряти настройки для конкретних попереджень компілятора, які можуть попереджати вас про деякі типи невикористаного коду. (Виберіть проект у списку джерел і Файл> Отримати інформацію, а потім виберіть вкладку Збірка.) Ось декілька (які відображаються для Clang та GCC 4.2 для мене), які можуть представляти інтерес:
Я не бачу жодних варіантів виявлення невикористаного імпорту, але це трохи простіше - низькотехнологічний підхід - це просто коментувати заяви про імпорт, поки не з’явиться помилка / попередження про компіляцію.
Невикористані методи Objective-C виявити набагато складніше, ніж невикористані функції C, оскільки повідомлення динамічно розсилаються. Попередження або помилка можуть сказати вам, що у вас є потенційна проблема, але її відсутність не гарантує, що у вас не буде помилок під час виконання.
Редагування: Ще одним хорошим способом виявлення (потенційно) невикористаних методів є вивчення покриття коду від фактичних виконань. Зазвичай це робиться в тандемі з автоматизованим тестуванням одиниць, але цього не повинно бути.
Ця публікація в блозі є гідним вступом до тестування одиниць та охоплення коду за допомогою Xcode. У розділі gcov(який, до речі, працює лише з кодом, згенерованим GCC), пояснюється, як отримати Xcode для побудови інструментального коду, який може записувати, як часто він виконується. Якщо ви взяли інструментальну збірку своєї програми для спіну в симуляторі, а потім запустіть gcov на ній, ви зможете побачити, який код був виконаний, використовуючи такий інструмент, як CoverStory (досить спрощений графічний інтерфейс) або lcov(сценарії Perl для створення звітів HTML) .
Я використовую gcovі lcovдля CHDataStructures.framework та автоматично генерую звіти про покриття після кожної фіксації SVN. Знову ж таки, пам’ятайте, що нерозумно трактувати виконане покриття як остаточну міру того, який код є "мертвим", але це, безумовно, може допомогти визначити методи, які ви можете дослідити далі.
Нарешті, оскільки ви намагаєтесь видалити мертвий код, я думаю, що ви також знайдете це питання ТАК цікавим:
Ми використовували домашній Ruby-код, який тепер витягується в дорогоцінний камінь під назвою fui: https://github.com/dblock/fui
Нещодавно я написав сценарій пошуку невикористаних (або копій) #importтверджень: https://gist.github.com/Orangenhain/7691314
Сценарій бере файл ObjC .m і починає коментувати по #importчерзі кожен рядок і бачити, чи проект все ще компілюється. Вам доведеться змінити BUILD_DIR & BUILD_CMD.
Якщо ви використовуєте findкоманду для дозволу запуску сценарію над декількома файлами, переконайтеся, що ви використовуєте BUILD_CMD, який фактично використовує всі ці файли (або ви побачите файл з великою кількістю невикористаних заяв про імпорт).
Я писав це, не знаючи, що у AppCode є схожа особливість, проте, коли я тестував AppCode, він був не таким ретельним, як цей сценарій (але набагато швидше [для цілого проекту]).
Як сказав Paddydub , AppCode роблять це дуже добре. Я спробував, і це зайняло у мене всього 10 хвилин:
Перейти до Code > Optimize Imports..., або^ + ⌥ + O
Ось відео, що описує, як це зробити: Виявлення невикористаного імпорту та методів у AppCode
Ви можете скористатися аналізатором Xcode для пошуку та інших проблем.
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
Також ви можете перейти до проекту та націлити збірку та додати налаштування попереджень про зміну в налаштуваннях збірки. Дивіться це керівництво:
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
Нещодавно я змінив великий проект з Carbon на Cocoa. Наприкінці цього було досить багато осиротілих файлів, які вже не використовувались. Я написав сценарій, щоб знайти їх, які по суті зробили це:
Переконайтеся, що джерело все зареєстровано на підрив (тобто чистий) Переконайтеся, що воно наразі створюється без помилок (тобто xcodebuild повертає 0 статус) Потім для кожного вихідного файлу в каталозі порожнє (тобто видаліть вміст, усікайте довжину) вихідний і заголовочний файл, спробуйте збірку, якщо вона не вдається, відновіть файли, інакше залиште їх порожніми.
Після цього запустіть, поверніть та видаліть усі випорожнені файли, компілюйте та видаліть усі помилки #imports.
Я також повинен додати, вам потрібно уникати файлів, на які посилаються файли .xib або .sdef, і можуть бути інші випадки динамічного посилання, але це все одно може дати вам хороший результат щодо того, що можна видалити.
Ця ж методика може бути використана для того, щоб побачити, який #imports можна видалити - замість обрізання файлу, видаляйте по черзі кожен #import у файлі і дивіться, чи не вдалося збірка.
id, або створюєте селектор для виклику під час виконання, статичний аналізатор не може гарантувати що код справді не використовується. Якщо код, який все ще потрібен, видалено, саме там ви отримаєте помилки під час виконання. Я щось пропускаю?