Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Dave <email@hidden>
- Date: Mon, 01 Jun 2015 19:11:04 +0100
> On 30 May 2015, at 02:25, Graham Cox <email@hidden> wrote:
>
>
>> 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 problem is that it makes the init method less readable and more error prone.
> 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.
So can extra braces along with just about everything else you write!
>
> 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.
Exactly, so make it more readable, to me anyway, unnecessary braces just add to complexity or at least makes the method look more complex than it actually is.
Cheers
Dave
_______________________________________________
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