The second and third personal feelings are extremely irregular.
The first one is a more old-fashioned way of writing, but NSString *_test; This is redundant, this is more old-fashioned, at that time the getter setter had to be written by hand
Because with the synthesize automatic property synthesizer, Xcode has already done this step for you.
I also wrote the default getter setter method for you. The underline is the identifier. This is an element variable to distinguish the formal parameters (local variables) in the getter setter.
In m files, you can directly assign values to underlined member variables, but the specification still recommends using self.test to operate like this, unless you are in a setter getter method, then you cannot use this.
There is also Google’s objc code style, haha, the member variables are underlined at the end, test_, are you dizzy again? I guess this style is to completely distinguish between pure member variables and attributes. That is to say, the underlined ones are purely used by the class itself. There are no getters and setters, and there is no need for other classes to access them.
Finally, as early as Xcode 4.6, or even earlier, I can’t remember, there is no need to write synthesize at all, Xcode has already written @synthesize test = _test for you.
So the simplest idea now is that if your variable is to be accessible to other classes, then you can just write @property directly.
Declare member variables NSString *_test; and attribute synthesizer @synthesize test = _test, no need to write,
If your variable does not need to be accessed from outside the class at all, then you can declare a member variable yourself NSString *test_; don’t write anything else. The initialization place initializes the release of the release
//----------------
I found that I have been downvoted. My personal understanding may be wrong. Please point it out if I am wrong. Thank you,
What I said at the end was a bit loose~ I didn’t mention the difference between h and m.
In h, if there are only member variables, although there are no getters and setters, subclasses can still access them. Attributes are equivalent to being public.
Use properties instead of instance variables whenever possible. In addition to accessing instance variables synthesized by properties in initialization methods (init, initWithCoder:, etc.), dealloc methods, and custom setter and getter methods, properties are used for access in other cases.
When you use the @synthesize directive, the compiler will automatically create an instance variable starting with an underscore _ for you, so there is no need to declare instance variables and attributes at the same time.
Don’t use @synthesize unless required by the compiler. Note that @optional optional properties in @protoco protocols must be explicitly synthesized using the @synthesize directive.
Reference: iOS App Development Best Practices Series 1: Writing High-Quality Objective-C Code
The third type, but not exactly like you, should be:
#import "Test.h"
@interface Test ()
@property (nonatomic, copy) NSString *test;
@end
@implementation Test
@synthesize test = _test;
@end
About why underline is used
An Objective-C property usually has a helper ivar.
The property may have a different name than ivar.
For instances, you might have an ivar called ivarName, and a property called propertyName.
You can synthesize propertyName to the ivarName variable, via:
@synthesize propertyName = ivarName;
About using underscores.
Using an underscore before an instance variable is a common way of writing . This can prevent name conflicts or compiler warnings when instance method parameters and instance variables have the same name.
The underscore prefix also makes it clear that you are referencing an ivar.
By using an underscore prefix for instance variables, you are free to use names without underscores in method parameters, stack variables, etc.
But when you use a property, you generally don't want the user to write an underscore, so you usually take a property called _ivarName for an instance variable called ivarName.
That's why you write:
synthesize can be used to define attributes, and it will automatically generate get/set.
Personal opinion:
* If you define externally visible attributes, I think the simplest method three should be used for the reason of simplicity.
* If you are defining internal properties or variables, it is recommended to define them in a .m or .mm file to reflect the meaning of hiding them from the outside (of course they cannot be truly hidden).
* If it is an internal variable with value semantics, using synthesizesize will not only have no benefit, but will also increase runtime overhead.
The second and third personal feelings are extremely irregular.
The first one is a more old-fashioned way of writing, but NSString *_test; This is redundant, this is more old-fashioned, at that time the getter setter had to be written by hand
Because with the synthesize automatic property synthesizer, Xcode has already done this step for you.
I also wrote the default getter setter method for you. The underline is the identifier. This is an element variable to distinguish the formal parameters (local variables) in the getter setter.
In m files, you can directly assign values to underlined member variables, but the specification still recommends using self.test to operate like this, unless you are in a setter getter method, then you cannot use this.
There is also Google’s objc code style, haha, the member variables are underlined at the end, test_, are you dizzy again? I guess this style is to completely distinguish between pure member variables and attributes. That is to say, the underlined ones are purely used by the class itself. There are no getters and setters, and there is no need for other classes to access them.
Finally, as early as Xcode 4.6, or even earlier, I can’t remember, there is no need to write synthesize at all, Xcode has already written @synthesize test = _test for you.
So the simplest idea now is that if your variable is to be accessible to other classes, then you can just write @property directly.
Declare member variables NSString *_test; and attribute synthesizer @synthesize test = _test, no need to write,
If your variable does not need to be accessed from outside the class at all, then you can declare a member variable yourself NSString *test_; don’t write anything else. The initialization place initializes the release of the release
//----------------
I found that I have been downvoted. My personal understanding may be wrong. Please point it out if I am wrong. Thank you,
What I said at the end was a bit loose~ I didn’t mention the difference between h and m.
In h, if there are only member variables, although there are no getters and setters, subclasses can still access them. Attributes are equivalent to being public.
In m, everything is private.
Use properties instead of instance variables whenever possible. In addition to accessing instance variables synthesized by properties in initialization methods (init, initWithCoder:, etc.), dealloc methods, and custom setter and getter methods, properties are used for access in other cases.
Good style:
Bad style:
When you use the @synthesize directive, the compiler will automatically create an instance variable starting with an underscore _ for you, so there is no need to declare instance variables and attributes at the same time.
Bad style:
Good style:
Don’t use @synthesize unless required by the compiler. Note that @optional optional properties in @protoco protocols must be explicitly synthesized using the @synthesize directive.
Reference: iOS App Development Best Practices Series 1: Writing High-Quality Objective-C Code
Norms
The third type, but not exactly like you, should be:
About why underline is used
An Objective-C property usually has a helper ivar.
The property may have a different name than ivar.
For instances, you might have an ivar called
ivarName
, and a property calledpropertyName
.You can synthesize
propertyName
to theivarName
variable, via:About using underscores.
Using an underscore before an instance variable is a common way of writing . This can prevent name conflicts or compiler warnings when instance method parameters and instance variables have the same name.
The underscore prefix also makes it clear that you are referencing an ivar.
By using an underscore prefix for instance variables, you are free to use names without underscores in method parameters, stack variables, etc.
But when you use a property, you generally don't want the user to write an underscore, so you usually take a property called
_ivarName
for an instance variable calledivarName
.That's why you write:
synthesize can be used to define attributes, and it will automatically generate get/set.
Personal opinion:
* If you define externally visible attributes, I think the simplest method three should be used for the reason of simplicity.
* If you are defining internal properties or variables, it is recommended to define them in a .m or .mm file to reflect the meaning of hiding them from the outside (of course they cannot be truly hidden).
* If it is an internal variable with value semantics, using synthesizesize will not only have no benefit, but will also increase runtime overhead.
In the latest Xcode, just define @property directly without @synthesize. The compilation system will automatically add it for you when compiling.
property is recommended to be underlined. instance variable is not added.
@interface RNCSection: NSObject
@property (nonatomic) NSString *headline;
@end
It’s best to do this directly, it will automatically generate getter setter methods
Same question, I am also confused.
Use Swift and you won’t have to worry about it anymore
If the private variable in the .m implementation only wants others to get it, but does not want others to set it, how to write it?