This question already has answers here:
How does an underscore in front of a variable in a cocoa objective-c class work?
(9 answers)
Closed 9 years ago.
being relative new to programming iOS apps, I find it very useful to start off with some sample code.
Hence, I ended up with a .m file, that starts with some lines that look like
#synthesize valueOne= _valueOne;
I noticed that having such a syntax makes it impossible to programmatically set properties of valueOne, for instance doing things like
valueOne.tag = 3
Therefore, for my own purposes, I have outcommented the "=_valueOne" part, without any noticeable harm to the functionality of the code.
What is the significance of such syntax, and what has been the consideration of the author of my sample code to use it?
Thanks in advance
This syntax is synthesizing the backing ivar for valueOne under the name _valueOne. You can simply write your code to look like
_valueOne.tag = 3;
That said, it's generally considered better to use the property accessors whenever possible, so you'd typically write this as
self.valueOne.tag = 3;
The notable exceptions to this are when you're in -init, -dealloc, or your own custom getter/setter you still want to use the ivar directly.
Using a prefixed underscore on ivar names is generally considered good practice, because it means if you write valueOne.tag = 3; and you meant to use the property, you get a compiler error instead of silently using the ivar. If you intend to use the ivar, you can just use the underscore prefix, as _valueOne.tag = 3;.
This is such a common practice that the auto-synthesis behavior of modern clang will use the leading-underscore style for ivars. This means that if you delete the #synthesize line entirely, it will behave as though you had #synthesize valueOne = _valueOne;.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
#property #synthesize
I'm a little confused on the 2 methods, could someone please explain them to me?
What do they do, and why are they better than just using -(void)variable; and -(void)variable{}?
It's just a more convenient way to define standard getter/setter methods for your variables, because writing all over and over again simple standard getter and setter methods can be a real pain in the ... And properties provide an easy way to memory management (e.g. strong, nonatomic and so forth).
What do they do
They declare and implement property accessor methods (the getter and setter), respectively. #property declares, #synthesize tells the compiler to issue an autogenerated implementation for the declared methods.
why are they better than just using -(void)variable; and -(void)variable{}?
Because they're shorter, so more concise and make code more readable. Also, they have no errors in themselves - if you were to write a bunch of accessor methods, I'm sure you'd eventually miss something and you couldn't for the love of God tell where a mysterious segmentation fault came from. This doesn't happen with declared properties (so they are called).
One minor caveat is that old Objective-C compilers don't support declared properties. It might be the case (although there's very little chance for it) that one day you'll need to compile your code with an old compiler and it would be impossible because of this syntax. But again, this is very unlikely to happen.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?
Why rename synthesized properties in iOS with leading underscores?
I am a green hand in iOS programming.
I always see such a statement in other's code
#synthesize textNoteOrLink = _textNoteOrLink;
What is the meaning of the underline anyway? Can we just 'textNoteOrLink' in that case.
Yes you can just write textNoteOrLink.
Many developers put an underscore at the start of instance variable names (#synthesizing a property actually adds an ivar for that property) to avoid accidentally using the ivars instead of the property, bypassing setters and getters.
IMHO it's a good thing to do, but if you don't like it, just don't use it, but be cautions not to confuse properties and ivars.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Underscore prefix on property name?
What does this mean? #synthesize window=_window; I know that in general it means that 'some class' has a window, but why use _window instead of just window? Is this a namespace thing?
I'll give a go at describing this programming convention in basic English.
It is a very common convention in other languages to name member variables with a preceding m, m_, or _ to distinguish them from locally declared variables and to signify that they should have accessors written, if necessary (no classInstance.m_Variable = 5).
If an Objective-C programmer declares ivars following this convention (and they should) and uses the basic syntax #synthesize _window; then the usage for the property becomes somewhat ugly: classInstance._window = myWindow or [classInstance set_window:myWindow]. Using the syntax #synthesize window=_window; allows the Obj-C programmer to utilize a popular programming standard (preceding ivars with _) while simultaneously having property accessors that use the Apple standard classInstance.window = myWindow and [classInstance setWindow:myWindow].
This is a very common thing to do in iOS programming/objective-C, it has to do with ivars. For more information you can read here:
Why rename synthesized properties in iOS with leading underscores?
How does an underscore in front of a variable in a cocoa objective-c class work?
Based on my experience in having this habit in my code, it helps me to accidentally writing window when you mean self.window and vice-versa (doesn't have to be window, but any other variables as well)
short answer is: the underscore is just a convention useful to stress the fact that class variables are "private" to a class and you should access them via their properties.
you could declare your window variable without the leading underscore; in this case the #synthetize statement would be simply: #synthetize window, and it would be practically the same.
for the long answer, the links posted by aherlambang are really interesting read...
This question already has answers here:
Closed 11 years ago.
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?
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_;
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.
It uglifies the code, I hate ugly code.
It ads unnecessary typing for each variable you use and reference.
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.
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.
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.
This question already has answers here:
How do I declare class-level properties in Objective-C?
(10 answers)
Closed 8 years ago.
To declare an instance property you can use a declaration similar to this:
#property (readonly) int size;
The property can later be accessed using the dot syntax:
NSLog(#"The object has a size of: %d", objectInstance.size);
However, I'd like to declare a class property so that, even without an instance, I can access it in this manner. For example:
NSLog(#"%d instances have been created.", ClassName.numberOfInstances);
I know I could always implement this behaviour using a class message and call it using the dot syntax anyway, but I'd prefer having a declared property and would benefit from the #synthesize directive for some of the properties.
Is this possible?
The short answer is that no, you can't. The compiler will not let you do it. You can see that when Apple has to do something similiar (like for the UIView implicit animation parameters) they use KVC compliant naming put do not declare them as properties.
The longer answer is that classes are objects and I can in fact envision some pretty grotesque hacks that involve proxy redirections that let you do it, but it is really not something I would recommend doing.