Cocoa 中的实例变量命名约定答案

【问题标题】：Instance variable naming conventions in CocoaCocoa 中的实例变量命名约定
【发布时间】：2009-11-07 02:45:39
【问题描述】：

这个问题是关于objective c和cocoa中的变量命名风格。我只是想强调一下，我不是在寻找“正确”的答案，而是在寻找好主意。

我已经阅读了 Apple 和 Google 的 Objective c 风格指南，但我对它们中的任何一个都不是很满意。 Apple 的指南没有关于实例变量与局部变量的任何真正的风格建议。事实上，Cocoa 库本身似乎非常乐意拥有与实例变量同名的函数参数。这让我个人感到畏缩。

Google 指南指定实例变量应使用尾随下划线指示。好的，一切都很好，但它建议我们使用@synthesize property = property_ 合成每个公共属性。我不知道其他人，但如果我要对我项目中的每个实例变量都这样做，我会被诅咒的。我认为这是一种浪费且令人困惑的解决方案。

我很想为对象属性使用 myX（例如“myInstanceVariable”）命名风格，但我很少在目标 c 中看到这种风格。

所以是的，你用什么？我不知道您发现有用的任何样式约定吗？您认为与实例变量同名的函数参数是否危险，尤其是在多个开发人员环境中？谢谢大家！

注意 - 正如许多人所指出的，我的术语在 OP 中不适用。如果原始措辞影响了清晰度，我深表歉意，但我认为这一点仍然很清楚。

【问题讨论】：

【解决方案1】：

我倾向于使用不带前缀的 实例变量 名称（请注意，“成员变量”是 C++ 主义，因为它暗示结构和类主要是可互换的，而在Objective-C)，并且在出现歧义的情况下，我使用 Smalltalk 约定，将参数按其类型命名为“a”或“an”，例如：

- (void)setFoo:(SOFoo *)aFoo;
{
    foo = aFoo;
}

（当然，在现代 ObjC 中，您会为此使用属性。）

使用theFoo 代替aFoo 也比较常见；查看this question的答案。

如果您真的担心冲突，Google 约定是有意义的。如果您使用Xcode text macro 或Completion Dictionary 或Accessorizer 之类的工具来生成指令，那么采用起来非常简单。

请注意，Cocoa key-value coding guidelines 几乎假设 (a) 您不为实例变量名称添加前缀/后缀，或者 (b) 您为它们实现（或合成）非前缀/后缀访问器。正如其他人提到的，不要使用 _ 前缀；它保留供 Apple 在其框架中使用。

【讨论】：

好答案。我同意为参数添加前缀比试图将约定硬塞到目标 c 实例变量中更干净。苹果文档描述了常见 NSObject 类型的约定，因此为您自己的类型扩展它非常有意义。我将其标记为答案，因为它最好地回答了我的问题的要点——避免在类函数中使用模棱两可的名称间距——并且没有添加任何奇怪的约定或变通方法。

【解决方案2】：

首先：Objective-C 中没有“成员变量”，有“实例变量”或“ivars”。

Google 不是 Objective-C 编码或 Mac 开发方面的任何权威。 Google 地球是一个 Qt 应用程序：'nuff 说。

我似乎记得看到过 Apple 为 Objective-C 提供的官方编码风格指南，目前我没有找到。不过，这篇文章是一个很好的总结：

找到了！以下是 Apple 官方的 Cocoa 编码指南：

【讨论】：

感谢您链接苹果指南。我认为其余的都是题外话。每个人似乎都热衷于利用他们对 c 术语分类的知识，但没有回答手头的问题。此外，谷歌可能没有发明目标 c，但在编码约定方面，它们肯定是一个有效的来源。在这种情况下，我认为 Apple 文档并没有明确说明这一点，而 Google 是。我只是碰巧不喜欢他们的回答。

【解决方案3】：

在 Cocoa 中，风格是使用 pascalCased（或者是 camelCased？我不记得了）名称；并将成员变量命名为与访问器方法相同的名称。（如NSInteger anInteger、- anInteger和- setAnInteger:）。

这可能不是最好的风格，但如果您打算使用 Cocoa 做任何工作，那么习惯它可能是个好主意，因为许多机制都假定这种特殊的命名约定。

【讨论】：

当然，我知道 getter/setter 强制约定，我不会偏离骆驼案。我的问题更多的是用于表示实例和成员变量之间差异的符号。实际上，您可以像 google 样式那样为任何变量合成具有任何名称的访问器方法，但这可能会导致 IMO 非常混乱。

【解决方案4】：

_foo 不是坏习惯。或者至少它不再是了。见：

【讨论】：

【解决方案5】：

m_variableName 对于成员变量也很常见。就个人而言，大多数时候，我只是为两个变量使用相同的名称，并区分this.varname 和varname。

【讨论】：

是的，我偶尔会看到 m_X，但是使用目标 c 中的 setter 约定，它看起来很混乱。设置M_variableName？我想如果你坚持使用点表示法，你会避免这种情况。
“m_”前缀是个坏习惯。单个前导下划线也是如此，除非您正在编写供 Apple 内部使用的代码。不幸的是，Apple 一直让一些示例代码项目在没有适当清理的情况下上街。
为什么 _foo 是个坏习惯？ Apple 无法将 ivars 添加到 Obj-C 1.0 代码中，因此他们无法破坏您的代码。据我了解，编译器在 Obj-C 2.0 中对它们进行了调整，因此尽管 Apple 可以破坏您的代码编译（易于修复），但已经编译的程序将继续工作。