Objective C 中的实例变量/方法参数命名

Question

人们在命名实例变量和方法参数时遵循什么约定 - 特别是当方法参数用于设置 ivar（实例变量）时？

在 C++ 中，我经常使用 m_ 前缀表示 ivars。 在 C# 中，我遵循纯粹使用 this. 来消除 ivars 歧义的惯例。 此后我也采用了 C++ 中的等效内容 (this->)。

在 Objective C 中，我尝试了一些东西，但没有一个看起来真正令人满意。

除非有人提出了一些非常好的建议，否则我会接受这样的事实：我必须妥协（但是请不要让我使用 args 前缀！），所以我有兴趣听听大多数人的意见——尤其是那些已经使用 ObjC 一段时间的人的意见。

在发布本文之前，我做了一些尽职调查，并在以下位置找到了一些很好的资源：

• 此风格指南 （简要提及我的主题）
• 此帖子（很多那里的前 C++ 程序员）

他们给了我一些想法，但我仍然渴望听到其他人在做什么。

[编辑] 只是为了澄清：具体来说，我正在寻找如何区分 ivars 和方法参数 - 无论是通过前缀还是其他技术。

[编辑2] 感谢所有的回复和讨论点。 我不会结束这个，只是想说，正如我在对已接受答案的评论中指出的那样，我已经采用了在 init args 前面加上 the 前缀的约定（以及在 setter args 前面加上 < code>new，无论如何我都在这样做）。 这似乎是最好的力量平衡——即使我自己并不热衷于审美。

Answer 1

正如您所注意到的，如果参数名称与实例变量冲突，Cocoa 风格将使用像 theValue 这样的方法参数名称。 然而，在 Objective-C 2.0 风格的代码中，这种情况应该不会出现很多次。 假设您（通常）不应该直接访问实例变量。 这主要是因为这样做绕过了 Cocoa 中的键值观察机制。 相反，我们期望您通过 getter/setter 方法访问和改变属性。 在 Objective-C 2.0 中，很容易声明这些属性并自动 @synthesize getter/setter，因此没有太多理由不使用它们。 事实上，在 64 位系统上，运行时会自动为您创建实例变量，从而无需声明它们并减少使用它们的冲动。

您应该直接访问实例变量的唯一时间是在 -init 和 -dealloc 方法中：

@interface MyObject : NSObject 
{
  id ivar;
}

@property (retain,readwrite) id ivar; //or whatever retain/copy/assign and read/readwrite makes sense
@end

@implementation MyObject
@synthesize ivar;

- (id)initWithIvar:(id)theIvar {
  if(self = [super init]) {
    ivar = theIvar;
  }

  return self;
}

- (void)dealloc {
  [ivar release];
}

在这些情况下应直接使用 ivar 的原因是因为 getter/setter可能会产生依赖于完全初始化实例的副作用，从而使它们在对象状态完全初始化的 -init 和 -dealloc 中变得危险。 在所有其他情况下，您应该使用 self.ivar （或 [self ivar] 和 [self setIvar:newValue]）。

似乎除 -initWithXX 之外的方法不应该存在命名冲突。 如果是的话，难道不应该将它们重构为不具有该参数或使类不具有实例变量吗？

这样就只剩下 -initWithXX 方法，您经常会在其中发现参数和 ivar 之间发生冲突。 对于这种情况，如果您确实无法忍受 Cocoa 风格，则可以使用您提到的任何方法。 使用 _ 前缀有效并且相对常见（我相信 @synthesize 的 setter 和 getter 在这种情况下会自动执行正确的操作，但您可能必须显式设置以 _ivar 作为支持）。

Answer 2

要完成所有已知的 Objective-C 样式指南，此处是 Google 版本。 他们所做的就是在成员变量名后面添加下划线。 例如BOOL isActive_;。
因此，做出选择并坚持下去。 我也更喜欢我的应用程序使用“_”前缀。

Answer 3

以下是 苹果做到了。

Answer 4

Apple 生成的示例代码通常使用“_”前缀。 我想我还看到一些使用 mFoo 或 m_foo。 有些根本不关心前缀，只使用普通名称，但是稍后会变得混乱。 通常，在定义方法参数时，命名约定是使用“a”、“an”、“the”或“new”前缀。 例如：

@interface Foo : NSObject {
    id _bar;
}
@property (nonatomic, retain) id bar;

- (id) initWithBar:(id)aBar;

@end

@implementation Foo
@synthesize bar = _bar;

- (id) initWithBar:(id)aBar {
    self = [super init];
    if(self != nil) {
        _bar = aBar;
    }
    return self;
}

@end

我发现这个约定非常有效。 我以前不关心前缀，但这有时会让事情变得混乱。 使用前缀清楚地表明它是一个实例变量。 Apple 在其 (iPhone) 示例代码中使用了 @synthesize bar = _bar 约定。

无论如何，实例变量通常不会被使用，所以如果你发现“_”前缀烦人也没关系，因为你会使用 [self bar] （或 self.bar 如果你喜欢这类事情的话）无论如何。

Answer 5

Obj-C 不像许多其他语言那样严格定义“风格”，这可能是一件好事，也可能是一件坏事，但这意味着大多数时候你需要自己找到一种好的编码风格。

您还可以通过 self. 访问 Obj-C 中的变量。 因此，如果您有实例变量 test，您可以通过 self->test 访问它，这是合法的并且始终有效。 但在大多数 Obj-C 程序员眼中它并不美丽。 它泄露了“秘密”，即对象实际上只是结构（更准确地说，对象引用是指向结构的指针），而实例变量实际上是结构成员。 这并不是说这真的是秘密，但 Obj-C 程序员似乎更喜欢在他们的代码中“隐藏”这一事实。

在名称中使用下划线“_”是一个非常糟糕的主意。 这里有人指出Apple为他们的代码保留了下划线，但实际上GCC已经为符号名称保留了下划线。 更准确地说，ANSI-C 标准已经规定，以两个下划线或一个下划线和一个大写字母开头的变量保留供编译器内部使用。 所以使用一个下划线理论上是有效的，但是一不小心名字以大写字母开头就失效了。

到目前为止，我尝试的是使用前缀 my、myName 代替 name，并使用前缀 self、selfName 代替 name； 乍一看有点奇怪，但在一大段代码中看起来并不算太糟糕。 至少立刻就让人觉得“与众不同”。 我也只是尝试了一个“i”，用 iName 代替 name（或 iname 代替 name），但我对这个解决方案不是很满意。

不过，我从来没有浪费时间考虑方法参数。 因为这并不重要。 这些变量与任何其他变量一样，除非它们被声明为常量。 它们甚至可以在方法内重新用于其他目的，因为它不会对调用者产生任何影响。 例如，

- (NSImage *)loadImage:(int)imageNumber
{
  NSImage * res;

  // Some code that assigns a value to res
  // ...  

  // Re-use imageNumber for a different purpose
  for (imageNumber = 0; ...; ...) {
     // Some code
  }

  return res;
}

我认为该代码没有问题。 为什么我必须声明第二个堆栈变量，只要名称仍然有意义（如果我没有在 for 循环中按数字迭代图像，则名称当然没有意义，在这种情况下我会使用一个不同的变量 - 编译器实际上可能在堆栈上只为两者保留一个 int ）。