Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Michael David Crawford <email@hidden>
- Date: Mon, 01 Jun 2015 16:16:31 -0700
The paper entitled "Goto Considered Harmful" - by Dijkstra? - was
criticizing spaghetti code. At the time, commonly used programming
languages did not have control flow statements like "if/then/else",
"do/while", "while" or "switch/case". Instead, other than fortran's
"do/continue" you had to roll your own control flow; often it was done
quite poorly.
If you're experienced with coding as well as careful about it, there's
no real good reason that one cannot use goto to create control flow
that's not built-in to the language. Despite that it is commonly
asserted that if you use goto, then you are clueless. That's just
wrong.
Assembly code doesn't really have control flow constructs. You make
them out of gotos - condition or unconditional branches.
Michael David Crawford, Consulting Software Engineer
email@hidden
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Mon, Jun 1, 2015 at 4:05 PM, pscott <email@hidden> wrote:
> On 6/1/2015 2:52 PM, Britt Durbrow wrote:
>>
>> I personally find early returns to be very useful, and also make use of
>> forward-jumping goto statements sometimes (i.e, goto bail;).
>
>
> FWIW, while I embrace both early returns and the goto statement where it
> makes sense, for the case you make, I would use a break statement inside a
> do block:
>
> #define end_do while (0)
>
> do {
> if ( bailCondition ) break;
> if ( someOtherBailCondition ) break;
> ...
> } end_do;
>
> This creates another level of indentation, but structurally, that's the
> point.
>
>> However, when working on somebody else's code (like, say, an open-source
>> library); I'll adopt their coding style, even if some of the things they do
>> make my eyes itch. ;-)
>
>
> We are cut from the same cloth, there.
>
> Paul
>
> --
> Paul Scott
> email@hidden
>
>
>
> _______________________________________________
>
> 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
_______________________________________________
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