Question: > 
> **Possible Duplicate:**  
> 
> [How does an underscore in front of a variable in a cocoa objective-c class work?](https://stackoverflow.com/questions/822487/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?

Answer: 
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](http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml) and use a [trailing underscore](http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Variable_Names#Variable_Names). So my ivars would be: `NSString *name_;`
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.