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

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

不要把Objective-C写成Java/ c# / c++等。

我曾经看到一个编写Java EE web应用程序的团队尝试编写Cocoa桌面应用程序。就好像它是一个Java EE web应用程序。有很多AbstractFooFactory、FooFactory、IFoo和Foo，而他们真正需要的只是一个Foo类，可能还有一个Fooable协议。

确保你不这样做的部分原因是真正理解语言的差异。例如，您不需要上面的抽象工厂和工厂类，因为Objective-C类方法和实例方法一样是动态分派的，并且可以在子类中重写。

#import "MyClass.h"

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

@implementation MyClass

如果您使用的是Leopard (Mac OS X 10.5)或更高版本，则可以使用Instruments应用程序来查找和跟踪内存泄漏。在Xcode中构建程序后，选择使用性能工具> Leaks运行>。

即使你的应用程序没有显示任何泄漏，你可能把对象保存得太久了。在Instruments中，您可以为此使用ObjectAlloc工具。在Instruments文档中选择ObjectAlloc乐器，并通过选择View > detail(它旁边应该有一个复选标记)来显示乐器的详细信息(如果还没有显示的话)。在ObjectAlloc详细信息中的“分配生命周期”下，确保选择“已创建和仍然存在”旁边的单选按钮。

现在，每当您停止记录应用程序时，选择ObjectAlloc工具将在“# Net”列中显示对应用程序中每个仍然活动的对象的引用数。确保不仅要查看自己的类，还要查看NIB文件的顶级对象的类。例如，如果你在屏幕上没有窗口，而你看到一个仍然存在的NSWindow的引用，你可能没有在你的代码中释放它。

尽量避免我现在决定称之为“新类别yaholism”的现象。当Objective-C的新手发现类别时，他们通常会疯狂地为现有的每个类添加有用的小类别(“什么?我可以添加一个方法来转换一个数字到罗马数字到NSNumber岩石上!”)。

不要这样做。

你的代码将更容易移植，更容易理解，因为没有几十个小类别方法散布在20多个基础类之上。

大多数时候，当你真的认为你需要一个类别方法来帮助简化一些代码时，你会发现你永远不会重用这个方法。

还有其他的危险，除非你对你的分类方法进行命名空间(除了疯狂的ddribin，还有谁会这么做呢?)，在你的地址空间中运行的苹果、插件或其他东西也有可能用相同的名称定义相同的分类方法，但副作用略有不同....

好的。现在你已经被警告过了，忽略“不要做这部分”。但是要极度克制。

使用标准的Cocoa命名和格式化约定和术语，而不是使用其他环境中使用的任何术语。有很多Cocoa开发人员，当他们中的另一个人开始使用您的代码时，如果它看起来和感觉上与其他Cocoa代码相似，那么它将更容易接近。

做什么和不做什么的例子:

Don't declare id m_something; in an object's interface and call it a member variable or field; use something or _something for its name and call it an instance variable. Don't name a getter -getSomething; the proper Cocoa name is just -something. Don't name a setter -something:; it should be -setSomething: The method name is interspersed with the arguments and includes colons; it's -[NSObject performSelector:withObject:], not NSObject::performSelector. Use inter-caps (CamelCase) in method names, parameters, variables, class names, etc. rather than underbars (underscores). Class names start with an upper-case letter, variable and method names with lower-case.

无论你做什么，不要使用Win16/ win32风格的匈牙利符号。甚至微软也在转向。net平台时放弃了这一点。