gotos

[Dave Jones]

in article <2009 at optilink.UUCP>, cramer at optilink.UUCP (Clayton Cramer) says:
> 
>> > Sometimes, gotos are perfectly justifiable because they vastly
>> > simplify and clarify you code.
>> 
>> And once in a long while, there is no better way.  A loooong while.
>> If I were running a software house, I'd be tempted to say that using
>> a goto -- except in fixing a program that already uses them -- means
>> having $50 docked from your pay.  It's not *forbidden*, you understand,
>> it's just that you have to want it really badly!
>> -- 
>> "Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
>> non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry
> 
> Exactly the right approach.  The last project I supervised, the engineers
> that worked for me would occasionally try to justify a goto.  Every single
       ^^^^^^ ^^^ ^^
> time, I demonstrated that the worst they were out was an automatic variable
> and maybe a do...while construct -- usually the do...while loop and an
> appropriate automatic variable were already there.
> 
> I accept the remote possibility that goto might be appropriate somewhere --
> just as I accept the remote possibility that leprechauns exist, and we've
> just never found them.
> 
> Clayton E. Cramer

( As always, insert smilie faces after every line that irks you.
  I really don't take all of this too seriously. )

No no no.  Threatening employees with punative fines is NOT the right
approach.  I find the idea repugnant.  Blechh! I trust that Mr. Spenser 
meant only that he feels strongly that a goto is a no-no.  I don't think 
he really meant that he has to bully his employees to get them to do it 
his way. He seems like a nice enough fellow. Texan, I think.

Mr. Cramer says that he has always been able to show that adding an
automatic variable and some extra tests can obviate the goto. 
Indeed 'tis true.  There's a famous proof to that effect.
Constructive proof.  Of course the resulting code is harder 
to read than the original, but it's purged of those malicious
communist-inspired gotos.  The "come-from" problem of labels, as it 
has been called, is replaced by the "set-where" problem of SLB's 
(Silly Little Booleans).  No improvement in my estimation.  If it
were, we could just run all of those evil programs through 
a filter that exorcises the daemon gotos, and leaves only morally
correct transpicuous code.  Sorry, it ain't that easy.  

I think Mr. Cramer will find that the readers of this group may not
be quite so willing to agree that his code transformations improve
their goto examples as his employees seem to be.

I am honored to be entrusted with  maintaining some of the hardest to 
read code you have ever seen. (Trust me on this one. It's true.)
So I am something of an expert on how to write for obfuscation.
I haven't been thrown by a goto yet.  That's just control flow.
Piece of cake. If you really want to scramble some heads, screw up the
data structure definitions!

One more thing.  The way I see it, the supervisor works for the 
engineer, not the other way around.  I'm about to embark on supervising
a year-long project. We'll see if I still have that attitude next April.



I can't believe this goto thing is starting all over again.


             Dave (finished = TRUE;) Jones