|
Posted by RedGrittyBrick on March 20, 2008, 12:12 pm
Please log in for more thread options Abigail wrote:
> _
> RedGrittyBrick wrote:
> ::
<snip>
> ::
> :: Edager W. Dijkstra. Go To Statement Considered Harmful. 1968.
> ::
> :: In nearly 30 years of programming I have completely avoided use of GOTO
> :: in a professional context. All I have seen continues to convince me that
> :: Dijkstra was right on this matter. YMMV.
>
> Dijkstra also wrote:
>
> "Please don't fall into the trap of believing that I am terribly
> dogmatic about [the goto statement]. I have the uncomfortable
> feeling that others are making a religion out of it, as if the
> conceptual problems of programming could be solved by a simple
> trick, by a simple form of coding disciple!"
>
> Edsger W. Dijkstra, personal communication, 1973.
> Quoted by Donald E. Knuth, "Structured Programming with the go to
> Statement", 1974.
>
> What Knuth and Dijkstra are saying is that it's not so much the use of
> "goto" that should be avoided, the real horror is unstructured programming.
> But most people only know the title of Dijkstra's paper, and not the
> content [1], let alone know what others have to say about it.
Guilty as charged. Perhaps I am unlucky in that almost all the examples
of GOTO I have had to wrestle with, have been in examples of "spaghetti
programming". It is certainly possible to write spaghetti code without
using GOTO, but use of GOTO seems to encourage this trend in many
programmers.
>
>
> I'm not afraid to confess I do use goto. I prefer:
>
> again:
> my $result = do_something;
> goto again if it_failed;
>
> over
>
> my $result;
> my $success = 0;
> until ($success) {
> $result = do_something;
> $success = 1 unless it_failed;
> }
OK. I don't prefer the former, but I see your point.
However, in this case do_something is three hundred lines, I hope you'd
consider putting it into a subroutine do_something() - or perhaps
re-factoring into several subroutines. The OP is looking for an
"alternative strategy" that doesn't involve subroutines. The OP appears
to be hoping that using GOTO will avoid the perceived difficulty of
reorganising code into well-formed subroutines or objects and methods.
I infer the OP prefers
...
<stuff>
...
<perhaps hundreds of lines of intervening code>
...
<similar stuff>
...
to be transformed into something like
...
my second_time = 0;
stuff:
<stuff probably containing many IFs / GOTOs for dissimilar bits>
if (second_time) goto continuation
...
<perhaps hundreds of lines of intervening code>
...
second_time = 1;
goto stuff:
continuation:
...
instead of
...
stuff("foo", ...);
...
<perhaps hundreds of lines of intervening code>
...
stuff("bar", ...);
...
sub stuff {
<various stuff>
}
I still feel that re-factoring unwieldy and repetitive code into
subroutines (or objects and methods) is a more useful skill to learn
than how to sprinkle GOTO statements into that unwieldy code.
--
RGB
| 
XML Sitemap