Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Britt Durbrow <email@hidden>
- Date: Mon, 01 Jun 2015 14:52:40 -0700
My take on it is that this is somewhat a style issue; and as such is quasi-religious in nature; with adherents on all sides of the issue with valid points to make.
But FWIW, my, er, “sect” (to take a metaphor slightly beyond the breaking point) adheres to something that looks like this (er, coded in Mail.app - take with appropriate grains of salt):
#define RSHOddBall_randomDictionaryCapacity (100)
@implementation RSHOddBall
-(instancetype)init
{
if(!(self=[super init])) return nil;
someIvar=12345;
someRandomDictionary=[NSMutableDictionary initWithCapacity:RSHOddBall_randomDictionaryCapacity];
return self;
};
Notes:
I code with the full capabilities of modern IDEs in mind; for example, I don’t worry about setting off macros in all caps as syntax highlighting takes care that; and if I see a macro that I don’t immediately know exactly what it does, well it’s definition is only a command-click away.
I do believe that for readability, braces should be lined up vertically. Yes, it makes the source code longer - but ‘comeon, we’ve got *very* high resolution monitors these days, we can fit a *lot* of text on them!
I happen to like an extra semicolon after a closing brace when it’s the end of the logical block. It’s just the way I like it to look (it feels ‘funny’ to me to have a statement end without one); the compiler ignores it. YMMV.
Within a class I’ll often use direct ivar access; but outside of it I’ll almost always use accessors (there are some oddball performance related exceptions to this, but they are always heavily documented on the variable declarations, and used in a tightly integrated class-cluster like situation, hence the *almost* always - but it’s the exception, definitely not the rule). Yes, I know that there are valid reasons to use accessors within the class, but for most of my code it’s not warranted. Transforming direct ivar access to use accessors is a simple regex search and replacement should I need to refactor it. Again, YMMV.
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) and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely, someObject->obviouslyAnIvar). I do, however, use them for doing pseudo-namespacing at levels below the project prefix (as evidenced by RSHOddBall_randomDictionaryCapacity).
I personally find early returns to be very useful, and also make use of forward-jumping goto statements sometimes (i.e, goto bail;).
However, when working on somebody else’s code (like, say, an open-source library); I’ll adopt their coding style, even if some of the things they do make my eyes itch. ;-)
_______________________________________________
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