Organize #import Statements for Objective-C/XCode

After several months of coding in Objective-C, I completely understand when I need an #import, how import statements cascade (ripple?), and when to use forwarding classes. I do not know how to aggregate imports to get them inside of <> instead of in quotes (although maybe that's just for frameworks)...

The problem is that I'm making a huge mess. I come from Java (and the heavy-handed IDE), so I just add imports as I see fit. Sometimes I add them to the interface, but since that's usually not necessary, I just add them to the top of the .m in question.

Today I started thinking: there must be some rules of thumb on how to organize this stuff. In fact, since Objective-C is a C superset, there are rules of thumb for everything, but I don't know them. How should I organize my imports? Particularly:

• When should I import in the .m?
• When should I import in the .h?
• Should I create .h files just for the sake of importing them (i.e., header files that just have imports in them)? 开发者_如何学编程If so, any hints on organizing that?

This is just a general idea of what I'm trying to figure out.

---

The <....> syntax is indeed just for frameworks. That doesn't mean you shouldn't create a framework to contain the core logic of your application though. Often this is a useful thing to do if you:

a) Need to provide support for loadable bundles that want to invoke aspects of your application logic (the bundle links to the framework, so does your application) b) Write multiple apps that share the same core logic

Your question is somewhat subjective and you will get developers who argues both ways, but a convention I follow is:

1. Never import class definitions in the .h file, unless you are subclassing it. Use forward @class directives for everything in the .h.
2. Only import class definitions into a .m as you find you need to use that class in the implementation.

Generally speaking, the .h does not need access to the class definition of its ivars, method arguments or return values. It only needs to know that they are classes, which is what @class allows you to do. It does need access to the class definition of anything you're subclassing, adding a category to, or (obviously) implementing a protocol for.

---

Forget about whether <...> is for frameworks or what. <...> checks the system header search path, while "..." checks the current dir in addition to. One thing to remember however, is that the <CoreFoo/CoreFoo.h> declaration is handled a little differently on the apple platform, but only as it relates to apple frameworks: CoreFoo.framework/Headers/CoreFoo.h is matched to CoreFoo/CoreFoo.h

---

When imports are inside <> instead of quotes, all this means is that you are importing something from a framework. In fact, when doing this, the import is typically in the style

#import <Foundation/Foundation.h>

The first Foundation, before the slash, is the name of the framework in question, and the second one is just a header file in that framework. That header file is just something like

#import <Foundation/NSObjCRuntime.h>
#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>
...
#import <Foundation/NSURLHandle.h>

including every file from that framework. You can do this too, and isn't a bad idea for components that need multiple imports (although in that scenario, you may want a separate public interface)

For the other stuff, following the rule of thumb that you want stuff to know about as little as possible, you only want to put the import in the header file if it's necessary (like for an ivar or superclass) but really it's a matter of taste.