views:

672

answers:

3

After working a long time on an iPhone app, I realized that my code it's quite dirty, containing several #import and methods that are not called or useful at all.

I would like to know if there's any compiler directive or way to detect those useless lines of code. Does Xcode have any tool to detect this?

+11  A: 

Xcode allows you to (un)check settings for specific compiler warnings that can warn you of some types of unused code. (Select the project in the source list and File > Get Info, then select the Build tab.) Here are a few (which show up for Clang and GCC 4.2 for me) which may be of interest:

  • Unused Functions
  • Unused Parameters
  • Unused Values

I don't see any options for detecting unused imports, but that is a bit simpler — the low-tech approach is just to comment out import statements until you get a compile error/warning.

Unused Objective-C methods are much more difficult to detect than unused C functions because messages are dispatched dynamically. A warning or error can tell you that you have a potential problem, but the lack of one doesn't guarantee you won't have runtime errors.


Edit: Another good way to detect (potentially) unused methods is to examine code coverage from actual executions. This is usually done in tandem with automated unit testing, but doesn't have to be.

This blog post is a decent introduction to unit testing and code coverage using Xcode. The section on gcov (which only works with code generated by GCC, by the way) explains how to get Xcode to build instrumented code that can record how often it has been executed. If you take an instrumented build of your app for a spin in the simulator, then run gcov on it, you can see what code was executed by using a tool like CoverStory (a fairly simplistic GUI) or lcov (Perl scripts to create HTML reports).

I use gcov and lcov for CHDataStructures.framework and auto-generate coverage reports after each SVN commit. Again, remember that it's unwise to treat executed coverage as a definitive measure of what code is "dead", but it can certainly help identify methods that you can investigate further.

Lastly, since you're trying to remove dead code, I think you'll find this SO question interesting as well:

Quinn Taylor
http://clang-analyzer.llvm.org/
slf
I'm not sure what your point is... The static analyzer can find a lot of problems, but if you dispatch a message to a variable typed as **`id`**, or create a selector to call at runtime, the static analyzer can't guarantee that the code is truly unused. If code that is still needed is removed, that's where you'd get runtime errors. Am I missing something?
Quinn Taylor
Furthermore, selectors that are created based on strings at runtime are quite common.
dreamlax
Of course, there are cases where your dynamic code might be better served by being more strongly type-cast (i.e. return something instead of an id).Runtime typing is a strong point of Cocoa/Objective-C programming, but sometimes maintenance and readability would be better served by thinking more about strong typing.
alesplin
Oh, I definitely agree. My rule of thumb is to statically type (as I would in Java) unless I really need dynamic typing, which is rare but happens on occasion. However, just interfacing with Cocoa classes (for example, specifying a delegate) can result in hard-to-trace dynamism and execution paths. Heck, any program with a run loop and multiple threads can be non-trivial...
Quinn Taylor
A: 

Recently, I changed a large project from Carbon to Cocoa. At the end of this, there were quite a few orphaned files that were no longer used. I wrote a script to find them that essentially did this:

Ensure the source is all checked in to subversion (ie clean) Ensure it currently builds without error (ie, xcodebuild returns 0 status) Then, for each source file in the directory, empty (ie, remove the contents, truncate the length) the source and the header file, try a build, if it fails, revert the files, otherwise, leave them empty.

After running this, revert and then delete all emptied files, compile and then remove all erroring #imports.

I should also add, you need to avoid files that are referenced from .xib or .sdef files, and there may be other dynamic linking cases, but it can still give you a good lead on what can be deleted.

The same technique can be used to see which #imports can be removed - instead of truncating the file, remove each #import in the file in turn and see if the build fails.

Peter N Lewis
+2  A: 

A quick and dirty method is to use the Project Find feature. Copy and paste a method name and search the project. If it only returns the method declaration, you are safe to delete it.

Mark Suman