Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Init methods #15

Closed
hollance opened this issue Nov 8, 2013 · 20 comments
Closed

Init methods #15

hollance opened this issue Nov 8, 2013 · 20 comments

Comments

@hollance
Copy link
Member

hollance commented Nov 8, 2013

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.

@ghost
Copy link

ghost commented Nov 8, 2013

I use Apple's method exclusively

Sent from my iPhone

On 8 Nov 2013, at 07:59, Matthijs Hollemans notifications@github.com 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
Copy link
Contributor

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
Copy link
Member Author

hollance commented Nov 8, 2013

@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?

@ghost
Copy link

ghost commented Nov 8, 2013

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

@icanzilb
Copy link
Member

icanzilb commented Nov 8, 2013

  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;
}

@ghost
Copy link

ghost commented Nov 8, 2013

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

@funkyboy
Copy link
Contributor

funkyboy commented Nov 8, 2013

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

Cesare Rocchi
studiomagnolia.com

On Nov 8, 2013, at 10:42 AM, Mic Pringle notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub.

@hollance
Copy link
Member Author

hollance commented Nov 8, 2013

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
Copy link
Contributor

gregheo commented Nov 8, 2013

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
Copy link
Contributor

funkyboy commented Nov 8, 2013

+1 on this.

On Nov 8, 2013, at 5:10 PM, Greg Heo notifications@github.com 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
Copy link

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
Copy link
Member

moayes commented Nov 8, 2013

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

@hollance
Copy link
Member Author

hollance commented Nov 8, 2013

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.

@ghost
Copy link

ghost commented Nov 8, 2013

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 notifications@github.com 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
Copy link
Contributor

gregheo commented Nov 8, 2013

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
Copy link
Member

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
Copy link
Contributor

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

On Nov 10, 2013, at 5:16 PM, rwenderlich notifications@github.com 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
Copy link
Contributor

ndubbs commented Nov 17, 2013

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
Copy link
Member

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

ndubbs added a commit that referenced this issue Dec 19, 2013
@ndubbs ndubbs closed this as completed Dec 19, 2013
@mralexgray
Copy link

@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 ✌️...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants