-
Notifications
You must be signed in to change notification settings - Fork 626
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
Comments
I use Apple's method exclusively Sent from my iPhone
|
I use this method for brevity:
The need for extra parens |
@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. |
- (instancetype) init
{
self = [super init];
if (self) {
. . .
}
return self;
} |
Yup. Agree with @icanzilb, we should always be using |
Good point. Cesare Rocchi
|
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. ;-) |
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 |
+1 on this.
|
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 |
I am not a fan of multiple returns. I almost always do like @ColinEberhardt. |
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
|
I stretched the truth a bit, @elephantronic – I do indeed use a super single line assignment like 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 |
My vote is same as Matthijs:
Reasoning: that's what is used in the default Apple templates. |
(I hope this does not start a flame on Apple's templates)
|
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? |
@ndubbs Yeah adding a section for that somewhere sounds great. |
@gregheo +1 re: or EVEN _BETTER_...
Relish in it.. don't flame it, lovers ✌️... |
How does everyone write their init methods?
I use:
The variations on this are endless. Apple seems to prefer this now:
But I also see people do this:
I like the first one because it just looks aesthetically pleasing to me.
The text was updated successfully, but these errors were encountered: