0

Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?

I found that in Apple's frameworks' header files , Apple name instance variable with prefix underscope inside a class interface. like the _delegate instance below:

@interface ClassName : NSObject {
    id _delegate;
}
@end

But is there any side effects if we follow this naming convention when defining our own instance variable? I've been searching the answer for this question for quite a long time.

In apple's Code Guideline, apple just said they reserve the methods name begin with underscore, they haven't mention any restriction about instance variable's naming problem.

My colleague said if you define instance variable begin with underscore might get collide with the framework if the name you pick exist in the framework's private header file. Is this possible or does this become a reason that we shouldn't use the name begin with underscore because apple might already used it?

Community
  • 1
  • 1
Jimmy
  • 1,094
  • 10
  • 22
  • 1
    Duplicates: [1](http://stackoverflow.com/questions/3521254/prefixing-property-names-with-an-underscore-in-objective-c) [2](http://stackoverflow.com/questions/5582448/underscore-prefix-on-property-name) [3](http://stackoverflow.com/questions/822487/how-does-an-underscore-in-front-of-a-variable-in-a-cocoa-objective-c-class-work) [4](http://stackoverflow.com/questions/837559/when-do-you-make-an-underscore-in-front-of-an-instance-variable) [5](http://stackoverflow.com/questions/2371489/why-do-you-use-an-underscore-for-an-instance-variable-but-not-its-corresponding) [...](http://goo.gl/7MBqn) – jscs Apr 11 '11 at 17:44

3 Answers3

3

There is no side-effect. But using an underscore makes reading code a lot easier when accessing private ivars and function parameter names.

For example let say you have NSString *_name; in your header file. Then in your code would read like so:

- (void)doSomethingWithName:(NSString *)name {
    // the underscore makes reading code easier
    _name = [name retain];
    name = [_name retain];  // you know right away that this is wrong
}

I personally follow Google Objective-C Style Guide and use a trailing underscore. So my ivars would be: NSString *name_;

Black Frog
  • 11,595
  • 1
  • 35
  • 66
3

To be honest, I named all my local private variable all with an underscore in a really big project and things start looking like this. _thisVar _thatVar _thisSavesSomething

In my 10 years of coding and working on big and small projects (where I have done this and not done this). DONT DO IT. It is a total WASTE OF TIME. (sorry for yelling).

My reasons are.

  1. It uglifies the code, I hate ugly code.
  2. It ads unnecessary typing for each variable you use and reference.
  3. It makes autocomplete a little bit more useless so now you have to type "_" + variable first name before xcode autocomplete can make a better match for your variable.
  4. You already can explicitly make variables private and public in your header file so no need to add a new naming convention eg "_" at the start of all your variables.

I might use an "_" for something really private, that I wanted to indicate that this is special. But I will pretty much never use it.

Hope this clears things up. John.

John Ballinger
  • 7,380
  • 5
  • 41
  • 51
  • 1
    Totally agree. Underscores for instance variables are sooo 90s. There are no accidents the underscore prevents. Whether you write x_ = y or self.x = y in the end it's no different from x = y and self.x = y. It only helps to remind you, but a good Objective-C programmer instinctively knows the difference. The problem is only with programmers not familiar with ObjC, and that naming convention may even prevent learning that aspect of ObjC. – CodeSmile Nov 16 '11 at 12:02
-1

In counter to John, I always prefix my local variables with an underscore, for one major reason - it prevents you from accidentally using the private variable instead of a public variable. The only time a private variable should be accessed is in init, dealloc, and assessor methods. Using a private variable accidentally can lead to bugs that can be difficult to track down and memory leaks.

Distec
  • 117
  • 1
  • 7
  • 1
    Your public variables should be properties. 'nuff said. – CodeSmile Nov 16 '11 at 11:59
  • I am sorry I disagree with you. This is the theoretical reason, but in practice this isn't an issue. Write clean clear code (_because _writing _stuff _like _this _makes _things _ugly). As with LearnCocos2D simply set your public vars to properties. – John Ballinger Nov 25 '11 at 00:49