2

I fairly new to IOS programming, and came over this the other day:

say you have a TestVC.h file:

@interface TestVC : UIViewController 
@property (strong, nonatomic) IBOutlet UIProgressView *progress;
@end

and in TestVC.m file (at the top):

@interface TestVC ()
@property (strong, nonatomic) NSArray *levels;
@end

When you use a variable from .h-file, you'd say self.progress

If you use a variable from the .m-file, it's _levels

What is the difference?

Nilzone-
  • 2,766
  • 6
  • 35
  • 71

2 Answers2

2

When you use a variable from .h-file, you'd say self.progress

If you use a variable from the .m-file, it's _levels

There is no difference. self.progress and _progress and self.levels and _levels are all perfectly functional.

However, the _ syntax is a tiny bit faster and the self. syntax is the proper way to do it except in a few cases where it's not. There are times when using _ will cause serious problems that are solved by using self.. And there are times when self. will cause problems.

Basically _ is accessing the raw memory address directly, and self. is accessing it "properly" using the objective-c language.

The difference between declaring a variable in *.m vs *.h is that the one in *.m is hidden, so nothing else in your source code can see that it exists. It is there but you will get a compiler warning that it doesn't exist. When it compiles it will work though, because really it does exist.

Basically declaring variables in *.m is a way of saying "this thing is here but I don't want anything outside this file to ever use it". It's purely cosmetic, has no impact on the how the app functions.

As a new Obj-C programmer, you should always use self.levels. Any time you see sample code using _levels I would change it to self.levels. If you run into problems... ask here to see if you've found a case where _levels should be used.

Abhi Beckert
  • 32,787
  • 12
  • 83
  • 110
  • -Basically declaring variables in *.m is a way of saying "this thing is here but I don't want anything outside this file to ever use it" So it's basically a way to make variables/functions private? – Nilzone- Dec 26 '13 at 17:23
  • Yeah, it's the same as making it private except it doesn't actually make it private. Note that iOS does support proper formal private properties, but in general Obj-C programmers prefer to do things by convention rather than with language restrictions. For example, making a method pseudo private instead of actually private means you can access it from unit tests or from a second class that is part of another class that is a companion class. A proper private property would not allow that flexibility. It's not private, it's just undocumented. – Abhi Beckert Dec 27 '13 at 10:11
  • Obj-C programmers trust the documentation/public API of a class rather than how it's technically implemented. The assumption is the implementation could change at any time (eg, properties declared in *.m could be renamed) but the official ones (anything in *.h) is always going to be around, even if the property is deleted or renamed the old property will still exist as an alias for the new behaviour. – Abhi Beckert Dec 27 '13 at 10:13
0

They can be used in either format regardless of their being declared in the .h or .m files.

Best practice is to use the getter/setter "self." format everywhere with the possible exception of init and dealloc methods where the "_" direct access method is generally deemed to be a better choice.

zaph
  • 111,848
  • 21
  • 189
  • 228