Objective-C中dealloc的首选编码风格是什么？

Question

我知道关于编码风格的讨论往往以灾难和无尽的火焰战结束,但这不是我想达到的目标.在过去十年中,我主要dealloc在Objective-C中看到了两种不同的编码方式.第一个也是最常见的一个是放在dealloc文件的底部.这也是Apple在Xcode默认模板中使用的样式.这背后的逻辑似乎dealloc是在对象的结尾接近时调用的,因此文件的结尾似乎是一个很好的比喻.

另一方面,有几个人倾向于dealloc直接置于@synthesize指令之下.在我看来,这有两个主要的缺点:

1. 文件的顶部变得杂乱无聊的代码.
2. 在课堂上找到必要部分比较困难,你必须向下滚动.

我认为的巨大优势是您可以在属性和相应的release消息之间建立直接的可视连接.

另一件事是弄乱已经发布的变量.虽然我不认为这是必要的,特别是在整个变量在dealloc结束后被解构的对象上下文中,我倾向于也只是变量.我习惯于在函数范围内对变量执行此操作,因此我只是符合我的编码风格.

这就是我的大多数课程的样子:

@implementation Bar

@synthesize foo;

- (void)dealloc
{
  [foo release], foo = nil;

  [super dealloc];
}

// Initializers and other methods…

我已经提到了一些优点和缺点.对于这个话题你有什么看法？什么是你在使用的编码风格dealloc和为什么？我还忘了提到其他优点和缺点吗？

我不想在这里开始一场火焰战争.我只是想知道你使用什么样的风格,如果你有特定的理由,或者这对你最终无关紧要.

Answer 1

我喜欢将dealloc实现放在初始化器下面.这样,当我添加一个新的实例变量时,我就记得release它就在init它之后.

此外,我发现使用该#pragma mark指令使浏览文件更加容易.所以我将这些init和dealloc方法"分组" 在一个名为"初始化器"的标题下.浏览文件时,使用这些标题可以更轻松地找到您要查找的内容而不会被dealloc方法分心.

它可能是无聊的代码,但人是重要的.

Answer 2

如果没有特定的理由,请不要将你的ivar设置为nall.它没有任何意义,最多掩盖程序员错误,你可以更好地发现而不是隐藏.

Answer 3

我的订单:

1. 合成和@dynamic指令(我在2011年的某个时候开始做这些;以前,他们使用了访问器实现)
2. 类方法(+load,+initialize,+sharedFoo,其他)
3. 初始化器
4. dealloc
5. finalize
6. 自定义访问器实现
7. 协议一致性方法,按协议分组(通常带有#pragma mark指令)
8. 通知处理程序方法(通常在类扩展中声明在顶部)
9. 其他方法(通常在类扩展中声明在顶部)

在dealloc方法内:

• 不要使用访问者消息,隐式(属性访问)或显式.调用部分解除分配的对象可能无法安全地使用任何不纯的自定义访问器.(初始化器也是如此.)
• 不要将ivars设置为nil.该对象被部分解除分配; 你为什么还要发信息？(如果你不是,那么没有什么可以看到ivars的价值.)
• (如果以某种方式将ivars设置为合适nil)不要滥用逗号运算符.类似表达式[foo release], foo = nil混合类型(首先void来自消息表达式,然后id来自赋值表达式).这些是单独的陈述; 这样写.
•  
  [super dealloc] 永远是最后一个,它上面总是有一条空行,强调它的存在.

当然,我也打开了"将警告视为错误",所以如果我忘记了[super dealloc],我就会破坏我的构建.

Answer 4

我把dealloc放在顶部,就在@synthesize指令下面.这是一个有点笨重,无聊的代码,但是非常重要的代码,所以它得到了最高的收费.此外,能够比较属性和发布是至关重要的.