Cocoa中实例变量命名规范

Question

这个问题涉及到Objective-C和Cocoa中的变量命名风格。我想强调一下，我不是在寻找“正确”的答案，只是希望得到好的想法。

我已经阅读了苹果和谷歌的Objective-C编码规范，但都不是很满意。苹果的指南并没有对实例变量和局部变量提出任何实质性的风格建议。事实上，Cocoa库本身似乎非常愿意使用与实例变量完全相同的函数参数名称。这让我个人感到不安。

谷歌的指南指定实例变量应该用下划线结尾来表示。好吧，都可以接受，但它建议我们使用@synthesize property = property_为每个公共属性合成实例变量。我不知道其他人怎么看，但我决不会为我的项目中的每个实例变量都这样做。我认为这是一种浪费和令人困惑的解决方案。

我倾向于使用myX（例如"myInstanceVariable"）的命名风格来表示对象属性，但在Objective-C中我很少见到这种风格。

那么，你们使用什么方法？有没有其他风格约定，你觉得函数参数与实例变量同名在多个开发者环境中是否危险？谢谢大家！

注意-正如许多人指出的那样，我的术语在原始帖子中使用不当。如果原始措辞影响了阐述清晰度，我深感抱歉，但我认为重点仍然清晰可见。

- DougW

Answer 1

我倾向于使用没有前缀的实例变量名称（注意，“成员变量”是C++的术语，因为它暗示了结构体和类主要是可以互换的，而这在Objective-C中并不是这样），在出现歧义的情况下，我使用Smalltalk的约定，用“a”或“an”加上参数的类型来命名参数，例如：

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

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

使用theFoo而不是aFoo也是相当常见的；请参阅这个问题的答案。

如果您真的担心冲突，Google惯例是有意义的。如果您使用Xcode文本宏或类似Completion Dictionary或Accessorizer的工具来生成指令，那么采用这种方式就非常简单。

请注意，Cocoa键值编码指南基本上假定您不会为实例变量名称添加前缀/后缀，或者您会为它们实现（或合成）非前缀/后缀访问器。正如其他人提到的，不要使用_前缀；它被保留供Apple在其框架中使用。

- Nicholas Riley

---

好的回答。我同意在参数前加前缀比试图将约定强加到Objective-C实例变量中更为清晰。苹果文档描述了这些约定在常见的NSObject类型的情况下，因此将其扩展到您自己的类型是完全有道理的。我将其标记为答案，因为它最好地回答了我的问题的主要观点 - 避免类函数中的模糊名称空间，并且没有添加任何奇怪的约定或解决方法。 - DougW

Answer 2

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

Google 不是 Objective-C 编码或 Mac 开发的任何权威。Google Earth 是一个 Qt 应用程序：就这样。

我记得曾经看到过苹果针对 Objective-C 的官方编码风格指南，但目前我找不到了。不过，这篇文章是一个相当不错的总结：

http://cocoadevcentral.com/articles/000082.php

找到了！这是苹果官方的Cocoa编码指南：

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

- NSResponder

---

感谢提供苹果指南的链接。不过我认为其余内容都离题了。大家似乎都很热衷于运用他们对C术语分类的知识，而不是回答手头的问题。此外，虽然Google并没有发明Objective-C，但在编码规范方面他们确实是一个可靠的来源。在这种情况下，我认为苹果文档并没有明确说明这一点，而Google则有。只是我恰巧不喜欢他们的答案。 - DougW

Answer 3

在Cocoa中，惯例是使用pascalCased（或者是camelCased？我总是记不住）的命名方式，并将成员变量命名为访问器方法的同名变量（例如NSInteger anInteger，- anInteger和- setAnInteger:）。这可能不是最好的风格，但如果您打算在Cocoa中做任何工作，习惯这种特定的命名约定可能是一个好主意，因为许多机制都假定了这种命名约定。

- Williham Totland

---

当然，我知道getter/setter强制规定的惯例，并且我不会偏离驼峰命名法。我的问题更多地是关于表示实例和成员变量之间差异的符号表示法。实际上，您可以使用任何名称为任何变量合成访问器方法，就像Google风格一样，但在我看来，那可能非常令人困惑。 - DougW

Answer 4

_foo 不是一个坏习惯。或者至少现在不再是了。看：

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html

- Ivan Sanchez

Answer 5

m_variableName 对于成员变量来说也很常见。 个人而言，大多数情况下，我会使用相同的名称来命名变量，并通过 this.varname 和 varname 来区分。

- Soufiane Hassou

---

是的，我偶尔见过m_X，但在Objective-C中使用setter约定似乎有点混乱。setM_variableName？不过，如果你坚持使用点符号表示法，就可以避免这种情况。 - DougW

“m_”前缀是一个不好的习惯。单个下划线也是如此，除非您正在为苹果公司编写内部使用的代码。不幸的是，苹果公司一直在让许多示例代码项目在没有适当清理的情况下发布。 - NSResponder

为什么_foo是个不好的习惯？苹果无法向Obj-C 1.0代码添加ivars，因此他们无法破坏你的代码。据我所知，编译器会在Obj-C 2.0中调整它们，因此尽管苹果可能会破坏您的代码编译（易于修复），但已经编译的程序将继续工作。 - Mike Abdullah