Cleaning up Objective-C code

Question

When working on complex problems, I find myself trying all sorts of solutions and, while doing my best to stay organized, the code can get quite messy. Objects may be changed and no longer be of use, while other times I may add snippets of code that do not end up being used by the program but are taking up space and possibly memory.

Aside from carefully reading through the program, are there ways of finding chunks of code that are not used by the program?

What are some tips you have found for cleaning up your program?

One small trick I found for checking that objects from the .h file are still used in the app and to check that they are properly deallocated/released is to use the "search all" function (cmd-shift-F) and search by the name of the object

Answer 1

While not necessarily helpful in finding unused chunks of code, I have found clang to be very useful cleaning up code and finding potential problems. There's also a nice front-end available.

Answer 2

I sometimes find that developers in my team delete the references to classes they no longer need - not the files themselves. I often go to the 'add existing files' action, browse through the file selector and delete 'non-grey' orphaned source files using a separate Finder window.

Answer 3

Press Delete

Answer 4

I know this is not the answer you're looking for, but using source control is probably the best way to handle these situations. When you're about to do some major refactoring or try something tricky, just create a branch, and later merge it in or throw it away.

Answer 5

What about the Snapshots feature in Xcode? It seems like if you are not keeping various branches long term then this is the way to go. Just focus on a single feature at a time and get it working and suitable for check in. If you have something that needs to be preserved do a check in to your source repository. Otherwise snapshot away and roll back as needed. If you really care about short snippets of code keep a text file of library of code snippets around. Perhaps sticking in a comment header for each snippet for later searching.

Answer 6

Here's an article about a few approaches to reporting code coverage in your application:

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

It's oriented toward Mac applications but mostly applies to iPhone stuff too (DTrace you can only use in the simulator)

As the article notes, this is a harder problem in objective-C than other languages since it's so easy to have a method that is called by performSelector, that static analysis would report as dead code even though it gets called (yes you can also do something similar in Javabut it's done far more rarely).

Probably the gcc warning flag is the best idea, along with careful examination of what it thinks are uncalled methods. Actually running every possible code path in an application is actually pretty hard, but if you have a smaller set of possibly functions to remove at least you can make choices more quickly so you wouldn't have to test every path...

EDIT: I should probably make clear that code coverage is a technique you can use to find "dead" code, which is what you were after

Answer 7

I know this is hard, but if you want your code to be quality when you finish all of your "testing out different solution" im afraid you have to ensure you are always commenting and/or deleting code you don't need as you go.

If you think about it this makes sense. If you keep on changing and renaming things then you either have to clean it up as you go, or clean it up at the end. It's a hard practice to get into but its either that or clean up at the end.

Often if you leave it until the end then it might be easier to just start a new project and copy the useful bits over.

Answer 8

Using source control is a big help, as after mucking around, you can diff the source to see the changes - great for finding debugging NSLogs and other quick hacks you forgot you added.

Tagging temporary code with a marker you can find is also a good idea. I tend to tag any code I haven't finished with NYI. For example, if I add an IBAction, but haven't written it yet, I have it do NSLog( @"myaction NYI" ). As I progress through development, I occasionally search the project for NYI and see if there are any I've forgotten to implement. Temporary or hack debugging code I tag with "// NYI delete" so I'll remember to come back and delete it.

For deleting unused code, I recently wrote a script that: checked that everything was checked in and that it built cleanly, then went through ever .h file in the project and emptied it and its associated .c/.cpp/.m/.mm file and then did a test build. If it still built, it continued, otherwise it reverted that file and continued to the next header file. After the script finished, I checked the subversion status to see which files it thought I could get rid of. I also had to avoid any files that were used by resources. It worked quite well.

I want to write a script that goes through ever file and removes each #include/#import line and checks if it still compiles to clean out all the excess includes, but I haven't got around to that.