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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
