Init methods about objective-c-style-guide

I use Apple's method exclusively

Sent from my iPhone

On 8 Nov 2013, at 07:59, Matthijs Hollemans [email protected] wrote:

How does everyone write their init methods?

I use:

• (id)init
  {
  if ((self = [super init])) {
  . . .
  }
  return self;
  }
  The variations on this are endless. Apple seems to prefer this now:

• (id)init
  {
  self = [super init];
  if (self) {
  . . .
  }
  return self;
  }
  But I also see people do this:

• (id)init
  {
  self = [super init];
  if (self == nil) return nil;

  return self;
  }
  I like the first one because it just looks aesthetically pleasing to me.

—
Reply to this email directly or view it on GitHub.

[ColinEberhardt]

I use this method for brevity:

- (id)init
{
  if (self = [super init]) {
    . . .
  }
  return self;
}

The need for extra parens ((...)) will certainly confuse, so if we use this form it really needs to be explained.

[hollance]

@micpringle Which Apple's method? The old one or the new one?

@ColinEberhardt You don't use extra parens? Doesn't that trigger a compiler warning?

@hollance Of the three options above, the second one.

[icanzilb]

1. we should these days return instancetype instead of id right?

2. I always use this one:

- (instancetype) init
{
  self = [super init];
  if (self) {
    . . .
  }
  return self;
}

Yup. Agree with @icanzilb, we should always be using instancetype

[funkyboy]

Good point.
+1.
@hollance will disagree :)

Cesare Rocchi
studiomagnolia.com

On Nov 8, 2013, at 10:42 AM, Mic Pringle [email protected] wrote:

Yup. Agree with @icanzilb, we should always be using instancetype

—
Reply to this email directly or view it on GitHub.

[hollance]

I'm OK with instancetype. I only use it on convenience constructors but it doesn't do any harm to put them on init methods as well. ;-)

[gregheo]

I use the last one:

- (instancetype)init {
  self = [super init];
  if (!self) return nil;

  // other stuff here

  return self;
}

Rationale: it keeps with the "happy path on the left margin" guideline. I hate having important init code inside an if.

[funkyboy]

+1 on this.

On Nov 8, 2013, at 5:10 PM, Greg Heo [email protected] wrote:

I do the first one:

• (instancetype)init {
  self = [super init];
  if (!self) return nil;

  // other stuff here

  return self;
  }
  Rationale: it keeps with the "happy path on the left margin" guideline. I hate having important init code inside an if.

—
Reply to this email directly or view it on GitHub.

[ricardo-rendoncepeda]

I tend to use @ColinEberhardt 's method, but I am totally on board with @gregheo 's rationale and will be happy to stick to that

[moayes]

I am not a fan of multiple returns. I almost always do like @ColinEberhardt.

[hollance]

I am not a fan of the "happy path on the left margin" guideline, unless there are more than a couple of if's. Sometimes nested if's are clearer, sometimes multiple returns are clearer.

I had never even heard of this "happy path" thing until this guide. I can tell you from experience debugging large systems, it usually works out better to have a single return statement, but I do occasionally have multiple returns if they are obvious and help the over all readability. (Or, quite frankly, if I feel like it at the moment.)

As for the init, I prefer the style where you assign self inside the condition, but that's just because it's easy to type and if statements don't bother me like they seem to bother my buddy @gregheo. I could see doing it the way apple does in their auto generated files, but definitely bit like Greg said. That's just insane. ;)

Sent from my iPhone

On Nov 8, 2013, at 12:37 PM, Matthijs Hollemans [email protected] wrote:

I am not a fan of the "happy path on the left margin" guideline, unless there are more than a couple of if's. Sometimes nested if's are clearer, sometimes multiple returns are clearer.

—
Reply to this email directly or view it on GitHub.

[gregheo]

I stretched the truth a bit, @elephantronic – I do indeed use a super single line assignment like if (!(self = [super init])) return nil; but for the site, I figured it's better to be clearer and split up the assignment and the check.

I'm not a strict "happy pather" but I like it as a general rule to keep the common/expected code path non-indented. I also have no problem with multiple returns, especially for error conditions such as [super init] returning nil.

[rwenderlich]

My vote is same as Matthijs:

- (id)init
{
  if ((self = [super init])) {
    . . .
  }
  return self;
}

Reasoning: that's what is used in the default Apple templates.

[funkyboy]

(I hope this does not start a flame on Apple's templates)

On Nov 10, 2013, at 5:16 PM, rwenderlich [email protected] wrote:

My vote is same as Matthijs:

• (id)init
  {
  if ((self = [super init])) {
  . . .
  }
  return self;
  }
  Reasoning: that's what is used in the default Apple templates.

—
Reply to this email directly or view it on GitHub.

[ndubbs]

For this topic we should stick with Apple's template. This isn't necessarily covered in any detail. Should this be added as a new section?

[rwenderlich]

@ndubbs Yeah adding a section for that somewhere sounds great.

[mralexgray]

@gregheo +1 re: if (self != [super init]) return nil;

or EVEN _BETTER_...

- (id) init { return self = super.init ? _aProp = @"aVal", self : nil; }

Relish in it.. don't flame it, lovers ✌️...