Clearing Objective-C Code

Question

When I work on complex problems, I find myself in a variety of solutions, and by doing my best to stay organized, the code can become quite dirty. Objects can be modified and will no longer be used, while in other cases I can add code snippets that are ultimately not used by the program, but take up space and possibly memory.

Besides a thorough reading of the program, are there any ways to search for fragments of code that are not used by the program?

What are some tips you found for cleaning your program?

One small trick I found to verify that the objects from the .h file are still in use in the application, and to verify that they are properly freed / freed, is to use the Search All function (cmd-shift-F) and search by object name

Answer 1

Here's an article on several approaches to code coverage in an application:

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

It is focused on Mac applications, but it is mainly used for iPhone (DTrace you can use only in the simulator)

As the article notes, the problem in objective-C is more complicated than in other languages, since it is so easy to get a method that executeSelector is called that static analysis will report as dead code, even if it is called (yes, you can also do something similar in Javabut, this is done much less often).

The gcc warning flag is probably the best idea, as well as a thorough study of what, in his opinion, are unclaimed methods. In fact, running any possible code path in the application is actually quite difficult, but if you have a smaller set of possible functions to delete, at least you can make a choice faster, so you don't have to check every path ...

EDIT: I should probably clarify that code coverage is a method that you can use to find the "dead" code that came after

EDIT2: The link is dead! I cannot find the cached version, and I cannot remember it well enough to generalize more about what it contained.

Answer 2

Although it is not always useful to find unused pieces of code, I found clang to be very useful to clear the code and find the potential of the problem. A front-end is also available there.

Answer 3

I know this is not the answer you are looking for, but using a control source is probably the best way to deal with these situations. When you are going to do some major refactoring or try something complicated, just create a branch and then merge it or throw it away.

Answer 4

What about the Snapshots feature in Xcode? It seems like if you do not keep different branches in the long run, then this is the way to go. Just focus on one function at a time and get it working and suitable for registration. If you have something to save, go to your original repository. Otherwise, snapshot and rollback as needed. If you really need short code snippets, save the text snippet library text file. It is possible to stick to the comment heading for each snippet for later searches.

Answer 5

I sometimes find that the developers on my team remove references to classes that they no longer need, and not the files themselves. I often go to the “add existing files” action, look at the file selector and delete the “non-gray” lost source files using a separate Finder window.

Answer 6

I know that it’s difficult, but if you want your code to be of high quality when you complete all your “testing of another solution”, I’m afraid that you should be sure to always comment and / or delete code that you don’t need how you go.

If you think about it, that makes sense. If you continue to change and rename things, you need to either clean it, or go, or clean it at the end. It is a difficult practice to get into it, or to either remove it at the end.

Often, if you leave it to the end, it may be easier to just start a new project and copy the useful bits.

Answer 7

Using a control source is a big help, since after shutting down you can split the source to see the changes - great for finding debugging NSLogs and other quick hacks you forgot added.

Marking the time code with a marker that you can find is also a good idea. I tend to tag any code that I haven't finished with NYI yet. For example, if I add IBAction but haven’t written it yet, I have NSLog (@ "myaction NYI"). As I progress through development, I sometimes looked for a project for NYI and saw if there were any that I forgot to implement. Temporary or hacked debugging code. I mark "// NYI delete", so I will remember that I will return and delete it.

To remove unused code, I recently wrote a script that: checked that everything was checked and that it was built cleanly, and then went through the .h file in the project and emptied it and the associated .c / .cpp / .m / .mm , and then performed a test build. If it is still built, it continued; otherwise, it returned this file and continued with the next header file. After completing the script, I checked the status of subversion to see which files it could get rid of. I also had to avoid files that were used by resources. It worked well enough.

I want to write a script that goes through any file and removes every line of # include / # import and checks if it compiles everything to clear all the excess, but I did not get to that.