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

使用LLVM/Clang静态分析仪

注意:在Xcode 4中，这是内置在IDE中。

你可以使用Clang Static Analyzer在Mac OS X 10.5上分析你的C和Objective-C代码(还没有c++)。安装和使用起来很简单:

从本页下载最新版本。 从命令行，cd到您的项目目录。 执行scan-build -k -V xcodebuild。

(还有一些额外的限制等等，特别是你应该在“调试”配置中分析一个项目——详情请参阅http://clang.llvm.org/StaticAnalysisUsage.html——但这或多或少就是它的总结。)

分析器然后为您生成一组网页，显示可能的内存管理和编译器无法检测的其他基本问题。

使用NSAssert和朋友。 我一直使用nil作为有效对象…特别是发送消息给nil在Obj-C中是完全有效的。 然而，如果我真的想确定一个变量的状态，我使用NSAssert和NSParameterAssert，这有助于轻松跟踪问题。

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

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.

不要忘记NSWindowController和NSViewController会释放它们所控制的NIB文件的顶级对象。

如果手动加载NIB文件，则在使用完该NIB的顶级对象后，需要负责释放它们。

#import "MyClass.h"

@interface MyClass ()
- (void) someMethod;
- (void) someOtherMethod;
@end

@implementation MyClass