我看到的苹果提供的示例将App委托视为一个全局数据存储，一种数据管理器。这是错误的。创建一个单例，并在App委托中实例化它，但不要将App委托用作应用程序级事件处理以外的任何东西。我衷心赞同这篇博客文章中的建议。这条线索暴露了我。

编写单元测试。您可以在Cocoa中测试许多在其他框架中可能比较困难的事情。例如，对于UI代码，您通常可以验证事物是否按照应有的方式连接，并相信它们在使用时能够正常工作。你可以很容易地设置状态和调用委托方法来测试它们。

在编写内部测试时，也不会有公共、受保护和私有方法可见性。

避免生成

Since you typically(1) don't have direct control over their lifetime, autoreleased objects can persist for a comparatively long time and unnecessarily increase the memory footprint of your application. Whilst on the desktop this may be of little consequence, on more constrained platforms this can be a significant issue. On all platforms, therefore, and especially on more constrained platforms, it is considered best practice to avoid using methods that would lead to autoreleased objects and instead you are encouraged to use the alloc/init pattern.

因此，而不是:

aVariable = [AClass convenienceMethod];

在可能的情况下，你应该使用:

aVariable = [[AClass alloc] init];
// do things with aVariable
[aVariable release];

当您编写自己的方法返回新创建的对象时，您可以利用Cocoa的命名约定，通过在方法名前加上“new”来标记接收方必须释放该对象。

因此，与其:

- (MyClass *)convenienceMethod {
    MyClass *instance = [[[self alloc] init] autorelease];
    // configure instance
    return instance;
}

你可以这样写:

- (MyClass *)newInstance {
    MyClass *instance = [[self alloc] init];
    // configure instance
    return instance;
}

因为方法名以"new"开头，你的API的使用者知道他们负责释放接收到的对象(例如，看NSObjectController的newObject方法)。

你可以通过使用你自己的本地自动释放池来控制。有关这方面的更多信息，请参见自动释放池。

其中一些已经被提到过，但以下是我能想到的:

Follow KVO naming rules. Even if you don't use KVO now, in my experience often times it's still beneficial in the future. And if you are using KVO or bindings, you need to know things are going work the way they are supposed to. This covers not just accessor methods and instance variables, but to-many relationships, validation, auto-notifying dependent keys, and so on. Put private methods in a category. Not just the interface, but the implementation as well. It's good to have some distance conceptually between private and non-private methods. I include everything in my .m file. Put background thread methods in a category. Same as above. I've found it's good to keep a clear conceptual barrier when you're thinking about what's on the main thread and what's not. Use #pragma mark [section]. Usually I group by my own methods, each subclass's overrides, and any information or formal protocols. This makes it a lot easier to jump to exactly what I'm looking for. On the same topic, group similar methods (like a table view's delegate methods) together, don't just stick them anywhere. Prefix private methods & ivars with _. I like the way it looks, and I'm less likely to use an ivar when I mean a property by accident. Don't use mutator methods / properties in init & dealloc. I've never had anything bad happen because of it, but I can see the logic if you change the method to do something that depends on the state of your object. Put IBOutlets in properties. I actually just read this one here, but I'm going to start doing it. Regardless of any memory benefits, it seems better stylistically (at least to me). Avoid writing code you don't absolutely need. This really covers a lot of things, like making ivars when a #define will do, or caching an array instead of sorting it each time the data is needed. There's a lot I could say about this, but the bottom line is don't write code until you need it, or the profiler tells you to. It makes things a lot easier to maintain in the long run. Finish what you start. Having a lot of half-finished, buggy code is the fastest way to kill a project dead. If you need a stub method that's fine, just indicate it by putting NSLog( @"stub" ) inside, or however you want to keep track of things.

我看到的苹果提供的示例将App委托视为一个全局数据存储，一种数据管理器。这是错误的。创建一个单例，并在App委托中实例化它，但不要将App委托用作应用程序级事件处理以外的任何东西。我衷心赞同这篇博客文章中的建议。这条线索暴露了我。

确保您收藏了调试魔术页面。这应该是你在寻找Cocoa bug的源头时碰壁的第一站。

例如，它会告诉你如何找到你第一次分配内存的方法，后来导致崩溃(比如在应用程序终止期间)。