Очистка кода Objective-C - PullRequest
       18

Очистка кода Objective-C

4 голосов
/ 25 августа 2009

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

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

Какие советы вы нашли для очистки вашей программы?

Одна маленькая хитрость, которую я нашел для проверки того, что объекты из файла .h по-прежнему используются в приложении, и для проверки того, что они должным образом освобождены / освобождены, заключается в использовании функции «поиск всех» (cmd-shift-F) и поиск по названию объекта

Ответы [ 7 ]

5 голосов
/ 25 августа 2009

Вот статья о нескольких подходах к отчетности по покрытию кода в вашем приложении:

http://seriot.ch/blog.php?article=20080728

Он ориентирован на приложения Mac, но в основном относится и к iPhone (DTrace можно использовать только в симуляторе)

Как отмечается в статье, эта проблема сложнее в target-C, чем в других языках, поскольку иметь метод, который вызывается executeSelector, настолько просто, что статический анализ будет отображаться как мертвый код, даже если он вызывается также можно сделать что-то подобное в Javabut, это делается гораздо реже).

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

РЕДАКТИРОВАТЬ: Я, вероятно, должен прояснить, что покрытие кода - это метод, который вы можете использовать, чтобы найти «мертвый» код, который вы и использовали после

РЕДАКТИРОВАТЬ 2: ссылка мертва! Я не могу найти кэшированную версию, и я не могу вспомнить ее достаточно хорошо, чтобы подвести итог о том, что она содержала.

3 голосов
/ 25 августа 2009

Хотя не обязательно полезно находить неиспользуемые фрагменты кода, я обнаружил, что clang очень полезен для очистки кода и выявления потенциальных проблем. Также имеется хороший интерфейс .

2 голосов
/ 25 августа 2009

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

2 голосов
/ 25 августа 2009

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

1 голос
/ 26 августа 2009

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

Пометка временного кода маркером, который вы можете найти, также является хорошей идеей. Я склонен пометить любой код, который я еще не закончил с NYI. Например, если я добавляю IBAction, но еще не написал, у меня есть NSLog (@ "myaction NYI"). По мере продвижения в процессе разработки, я время от времени ищу в проекте нью-йоркский проект и вижу, есть ли что-то, что я забыл реализовать. Временный или взломанный код отладки, который я помечаю как "// NYI delete", поэтому я не забуду вернуться и удалить его.

Для удаления неиспользуемого кода я недавно написал скрипт, который: проверил, все ли было проверено и правильно ли он собран, затем просмотрел любой файл .h в проекте и очистил его и связанные с ним .c / .cpp /. m / .mm файл, а затем сделал тестовую сборку. Если он все еще был построен, он продолжал, в противном случае он вернул этот файл и перешел к следующему заголовочному файлу. После того, как скрипт закончился, я проверил состояние Subversion, чтобы увидеть, из каких файлов он мог избавиться. Я также должен был избегать любых файлов, которые использовались ресурсами. Это сработало довольно хорошо.

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

1 голос
/ 26 августа 2009

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

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

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

1 голос
/ 25 августа 2009

Иногда я обнаруживаю, что разработчики в моей команде удаляют ссылки на классы, которые им больше не нужны - не сами файлы. Я часто захожу в действие «добавить существующие файлы», просматриваю селектор файлов и удаляю «не серые» потерянные файлы-источники, используя отдельное окно Finder.

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