• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Looking at self = [super init].
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looking at self = [super init].


  • Subject: Re: Looking at self = [super init].
  • From: Michael David Crawford <email@hidden>
  • Date: Mon, 01 Jun 2015 15:33:51 -0700

I've always used "m" to prefix ivars: mSpeed, mDistance.  I use "s"
for statics and "k" for constants.

I'd like to find a good convention for distinguishing properties but
haven't really found one that is appealing to me.
Michael David Crawford, Consulting Software Engineer
email@hidden
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Mon, Jun 1, 2015 at 3:14 PM, Charles Srstka <email@hidden> wrote:
> On Jun 1, 2015, at 4:52 PM, Britt Durbrow <email@hidden> wrote:
>>
>> I don't use underscores to prefix ivars. I think it's ugly, and unnecessary -- it doesn't help with namespacing (if a subclass and a superclass both declare _someVariable with the underscore they will collide just as badly as if they declare someVariable without one)
>
> Which is not at all, actually:
>
> #import <Foundation/Foundation.h>
>
> @interface Foo : NSObject
>
> - (void)fooLogAnIvar;
>
> @end
>
> @interface Bar : Foo
>
> - (void)barLogAnIvar;
>
> @end
>
> int main(int argc, const char * argv[]) {
>     @autoreleasepool {
>         Bar *bar = [Bar new];
>
>         [bar fooLogAnIvar];
>         [bar barLogAnIvar];
>     }
>     return 0;
> }
>
> @implementation Foo {
>     NSString *_anIvar;
> }
>
> - (instancetype)init {
>     self = [super init];
>
>     if (self == nil) {
>         return nil;
>     }
>
>     _anIvar = @"Foo";
>
>     return self;
> }
>
> - (void)fooLogAnIvar {
>     NSLog(@"Foo: _anIvar is %@", _anIvar);
> }
>
> @end
>
> @implementation Bar {
>     NSString *_anIvar;
> }
>
> - (instancetype)init {
>     self = [super init];
>
>     if (self == nil) {
>         return nil;
>     }
>
>     _anIvar = @"Bar";
>
>     return self;
> }
>
> - (void)barLogAnIvar {
>     NSLog(@"Bar: _anIvar is %@", _anIvar);
> }
>
> @end
>
> 2015-06-01 17:12:16.328 test[17203:2499855] Foo: _anIvar is Foo
> 2015-06-01 17:12:16.329 test[17203:2499855] Bar: _anIvar is Bar
>
>> and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely, someObject->obviouslyAnIvar).
>
>
> Non-underscored ivars vs. local variables, however, are not obvious at all, especially if the method is large.
>
> Charles
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >Re: Looking at self = [super init]. (From: Dave <email@hidden>)
 >Re: Looking at self = [super init]. (From: Britt Durbrow <email@hidden>)
 >Re: Looking at self = [super init]. (From: Charles Srstka <email@hidden>)

  • Prev by Date: Re: Looking at self = [super init].
  • Next by Date: Re: Looking at self = [super init].
  • Previous by thread: Re: Looking at self = [super init].
  • Next by thread: Re: Looking at self = [super init].
  • Index(es):
    • Date
    • Thread