Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Graham Cox <email@hidden>
- Date: Sat, 30 May 2015 11:25:41 +1000
> On 30 May 2015, at 3:22 am, Alex Zavatone <email@hidden> wrote:
>
> // We don't care if this gets long.
My take is that you’re rewriting a well-recognised idiom to solve a non-existent problem.
The well-recognised idiom makes it easy to verify it’s correct. Hiding a different construct inside a macro obscures that, making it harder to verify the code. It’s not “wrong” exactly, just harder to see at a glance that it’s right.
The non-existent problem you’re trying to solve is that the gap between a pair of braces could get large. So what? Early returns can be another source of bugs, so structural purists would tell you that you shouldn’t do that. Sometimes I think it’s justified, but not usually worthwhile. Another religious issue is whether matching braces should line up or not. Personally I prefer that they do, at the cost of an extra line. Because you aren’t doing that, your long distance between braces is bothering you, because you’re losing track of where it started (I assume that’s why it’s bothering you). If you line up the braces that is much less of an issue.
Source code is for humans, so it should be as readable as you can possibly make it. Macros often hinder that. Unaligned braces hinder that. Multiple statements per line hinder that.
Factoring code helps, so I’d suggest that’s the better way to solve this. (and it’s also beneficial when it comes to making sure that -initWithCoder: and other initializers that don’t correctly follow the designated initializer rule can get access to your common initialization. While this is rarely a problem, I did notice that the recent change to encourage the use of -initWithCoder: for unpacking NSViews from a nib breaks this long-standing rule and so a common init method that both can call is a simple workaround).
—Graham
_______________________________________________
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