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: Tue, 02 Jun 2015 11:09:09 +1000
> On 2 Jun 2015, at 10:15 am, Steve Mills <email@hidden> wrote:
>
>> It was my understanding that the destructor is called if you go out of
>> scope for any reason, even if it's a goto.
>
> Hmm, either I'm thinking of something else, or I just can't find the right docs.
I think Michael is correct a dtor is called no matter how the scope that it belongs to is exited.
But that doesn’t apply to us as Obj-C developers (not sure if Swift has the concept) as we can’t have stack-based objects.
But anyway, the argument is really about readability and not introducing bugs. If you have a complex method whose function can’t be determined at a glance (and that in itself could be a good argument for a refactoring) with multiple exit points rather than one clear exit point at the end, it can often be hard to follow the flow of control. If the function is later changed to return a different type (BOOL becomes int for example) then making sure all your exit points return the right thing is extra work. That said, early returns up front for bad parameters or obvious sanity check failures are likely to be more readable. Overall, the judgement isn’t a rule, it’s about the craft and style of programming.
Excessive indentation is bad, but probably on balance to be preferred (IMHO) to multiple exit points. Yes, the compiler turns all of those into a goto anyway (or at least a branch to the final RTS or whatever, it rarely inserts an RTS in the middle), but that’s completely hidden from us as it should be.
Maybe this is just down to one’s personal history. If that’s ever included extensive Pascal (as mine does) then early returns and gotos are almost anathema. If you cut your teeth on C-like languages, probably less so.
—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