Как обнаружить неиспользуемые методы и #import в Objective-C - PullRequest
98 голосов
/ 22 сентября 2009

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

Я хотел бы знать, есть ли какая-либо директива компилятора или способ обнаружить эти бесполезные строки кода. У Xcode есть какой-нибудь инструмент, чтобы обнаружить это?

Ответы [ 7 ]

66 голосов
/ 22 сентября 2009

Xcode позволяет (не) проверять настройки для определенных предупреждений компилятора, которые могут предупредить вас о некоторых типах неиспользуемого кода. (Выберите проект в списке источников и выберите «Файл»> «Информация», затем выберите вкладку «Сборка».) Вот некоторые из них (которые отображаются для Clang и GCC 4.2 для меня), которые могут представлять интерес:

  • Неиспользуемые функции
  • Неиспользуемые параметры
  • Неиспользуемые значения

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

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


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

Эта запись в блоге - это хорошее введение в модульное тестирование и покрытие кода с использованием Xcode. В разделе gcov (который, кстати, работает только с кодом, сгенерированным GCC) объясняется, как заставить XCode создавать инструментированный код, который может записывать, как часто он выполнялся. Если вы возьмете инструментальную сборку своего приложения для вращения в симуляторе, а затем запустите на нем gcov, вы можете увидеть, какой код был выполнен, используя инструмент, такой как CoverStory (довольно упрощенный графический интерфейс) или lcov (Perl-скрипты для создания отчетов HTML).

Я использую gcov и lcov для CHDataStructures.framework и автоматически генерирую отчеты о покрытии после каждой фиксации SVN. Опять же, помните, что неразумно рассматривать выполненное покрытие как окончательную меру того, какой код «мертв», но это, безусловно, может помочь определить методы, которые вы можете исследовать дальше.

Наконец, поскольку вы пытаетесь удалить мертвый код, я думаю, вам также будет интересен этот ТАК вопрос:

37 голосов
/ 10 апреля 2013

Appcode имеет функцию проверки кода, которая находит неиспользуемый импорт и код.

8 голосов
/ 22 января 2014

Мы использовали какой-то доморощенный код Ruby, теперь извлеченный в гем под названием fui: https://github.com/dblock/fui

5 голосов
/ 28 ноября 2013

Я недавно написал скрипт для поиска неиспользуемых (или дублирующих) #import операторов: https://gist.github.com/Orangenhain/7691314

Сценарий берет файл ObjC .m и начинает комментировать каждую строку #import по очереди и проверяет, все ли еще компилируется проект. Вам нужно изменить BUILD_DIR & BUILD_CMD.

Если вы используете команду find для запуска сценария над несколькими файлами, обязательно используйте BUILD_CMD, который на самом деле использует все эти файлы (или вы увидите файл с большим количеством неиспользуемых операторы импорта).

Я написал это, не зная, что AppCode имеет аналогичную функцию, однако, когда я тестировал AppCode, он был не таким тщательным, как этот скрипт (но намного быстрее [для всего проекта]).

2 голосов
/ 27 мая 2016

Вы можете использовать Xcode Analyzer, чтобы найти эту и другие проблемы.

http://help.apple.com/xcode/mac/8.0/#/devb7babe820

Также вы можете перейти к проекту и выполнить сборку и добавить настройки предупреждений об изменениях в настройках сборки. Смотрите это руководство:

http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

2 голосов
/ 30 мая 2014

Как сказал paddydub , AppCode делают это очень хорошо. Я попытался, и это заняло у меня всего 10 минут:

Перейти к Code > Optimize Imports... или ^ + ⌥ + O

Вот видео, описывающее, как это сделать: Обнаружение неиспользованного импорта и методов в AppCode

1 голос
/ 23 сентября 2009

Недавно я сменил крупный проект с Carbon на Cocoa. В конце этого было довольно много осиротевших файлов, которые больше не использовались. Я написал скрипт, чтобы найти их, которые, по сути, сделали это:

Убедитесь, что все источники возвращены в Subversion (т.е. очищены) Убедитесь, что он в настоящее время собирается без ошибок (т.е. xcodebuild возвращает 0 статуса) Затем для каждого исходного файла в каталоге очистите (то есть удалите содержимое, урежьте длину) исходный файл и файл заголовка, попробуйте выполнить сборку, если она не удалась, верните файлы, в противном случае оставьте их пустыми.

После этого верните, а затем удалите все очищенные файлы, скомпилируйте и удалите все ошибки # импорта.

Я также должен добавить, что вам нужно избегать файлов, на которые ссылаются файлы .xib или .sdef, и могут быть другие случаи динамического связывания, но это все же может дать вам хорошее представление о том, что можно удалить.

Та же самая техника может использоваться, чтобы увидеть, какие #imports можно удалить - вместо усечения файла по очереди удалите каждый #import в файле и посмотрите, не удалась ли сборка.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...