|
OriginalGriff wrote: it violates all the principles of good code design
Actually "good" code design is an evolving thing. When I started coding, spaghetti code was normal and "good" I much prefer today's standard of "good" and look forward to new definitions of good. Just read an article about how we should eliminate IF statements. Interesting, but you can see how the "IF" was encapsulated in the routine executed. But that is part of the new "good", encapsulate and re-use existing logic.
|
|
|
|
|
It (goto) is unattractive certainly, and it's usage rightly deprecated. But for my money it's a mere misdemeanour compared to the worst sin in programming, namely global data.
There are developers who would rather eat their own limbs than use a goto, yet happily employ global variables with lavish abandon, supremely oblivious to the misery they are imposing on those who inherit their code.
I'm currently engaged in modifying a legacy VB6 app comprising around half a million lines of code. The many goto's therein are tiresome but just about tolerable. The multitude of global variables, all absolutely unnecessary, all toxic in the extreme, guarantee that an innocent change in one source file results in incomprehensible failures in a dozen others.
I'll happily deal with all the goto's a naive developer cares to throw at me, if they would just understand and apply the simple notions of encapsulation and data hiding. Not that I'm justifying the goto mind, but there are far, far worse offences.
|
|
|
|
|
I didn't even realise that C# had a goto statement!
Now that I do know this I will now use it in a profligate manner - mwahahahahah!
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Noooooooooo! 
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
Nice, you can use it to replace all loop statements, but be careful! 
|
|
|
|
|
You have just gained a level. Instead of blindly following some master wizard's rules, you now have begun to make your own. Before you know it you will zap your opponents with pointy pointers and even manage memory yourself.
I actually prefer working with people who occasionally contemplate to break the rules instead of reciting them. 
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
Under the hood almost every code block that is put into curly brackets is implemented with machine instructions for conditional or unconditional branches. GOTOs, if you want. They have just been hidden away.
Unstructured spaghetti code is very hard to read and maintain. Readability and maintainability are even more important than correctness, at least in my book. Correctness will eventually follow as long as the code is readable.
What I don't like is when people start religiously following rules and can even recite the reasons for them, often obviously without understanding the intentions behind them. 'Bad' code may have some other advantage than readability. If that advantage in a specific situation becomes more valuable than readability, then I would happily do what needs to be done. I also would heavily comment it to document my reasons for doing this.
And the whole time I would enjoy the wailing of the code Nazis.
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
CDP1802 wrote: Under the hood almost every code block that is put into curly brackets is
implemented with machine instructions for conditional or unconditional branches.
GOTOs, if you want. They have just been hidden away.
I first cut my teeth on ICL System4 mainframes in 1979 and can still remember the conditional/unconditional branch instruction's machine code - 47 xx yy yy (I think JMP was it's assembler code mnemonic). XX was the condition, 0F was an unconditional branch. And YY YY was the prog address to go to. It's scary some of the completely useless info your brain retains.
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
“We didn't have a positive song until we wrote 'Now I Wanna Sniff Some Glue!'” ― Dee Dee Ramone
"The Democrats want my guns and the Republicans want my porno mags and I ain't giving up either" - Joey Ramone
|
|
|
|
|
In the olden day (60's and 70's mostly), goto was abused as much as (or more than) var is today. Some programmers resisted this, lead by E. Dijkstra. They gathered momentum, lost their rationality, became zealous, succeeded in converting all new and most old programmers to their Holy Cause. As a result, The Hivemind took the position that all use of goto is nothing less than Pure Evil(tm), and now prefers to use highly obfuscated but structured control flow where a simple goto would have solved the problem in a simpler way. The Hivemind, ever hypocritical, also suggests refucktoring "nested loops where you exit both of them from the inner loop" to a confusingly-named and nonsensical-on-its-own function with multiple returns, a practice that it itself also denounces.
|
|
|
|
|
harold aptroot wrote: The Hivemind, ever hypocritical, also suggests refucktoring "nested loops where
you exit both of them from the inner loop" to a confusingly-named and
nonsensical-on-its-own function with multiple returns, a practice that it itself also denounces.
You mean the old story recursion vs. iteration? The stuff some eggheads traditionally use to torture students in their first semester?
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
That's fun too, but no - I mean the thing where they place the loops in a function and the goto turns into a return, and then they pretend that isn't really the same thing.
|
|
|
|
|
Bur they aren't, and that's really the point. If all someone did was goto a label at the very end of a function, that would be ugly but not terribly problematic. The problem is that the goto ends up going to other logic. With many C developers, it was cleanup code (the destructors, so to speak) which wasn't so bad, but then someone would add more labels until you had a stack of exit conditions, sometimes intertwined. Then, inevitably, you'd find a goto from one scope to the middle of another and that's when you end up with really bad problems.
EDIT: To be very clear, the problem with goto is not, and never really has been, with exiting a context abruptly, especially with RAII, but in entering another context at an arbitrarily point.
modified 10-Nov-13 16:15pm.
|
|
|
|
|
I've made my living programming since 1980. I've written millions of lines of code in everything from C#, C++, C, to several assembly languages.
I've been writing C# since 2008. I've never needed to use goto.
I've been writing C++ since 2000. I've never needed to use goto.
My C code, written from 1990 to around 2002, used goto solely for exception handling. The Microsoft and Watcom C compilers at the time didn't support exceptions in a robust fashion.
Tarek Elqusi wrote: Troubles are based on the programmer who is misusing it
While that statement is true, the converse is not. I've never found a case in modern times where goto was necessary. There is always a structured alternative. If a programmer is good enough, they will not need goto.
Software Zen: delete this;
|
|
|
|
|
Ahh... This is one of my favourite subjects.
I think we went to the total unbalance of the overpopulation of gotos of BASIC to the total unbalance of goto starvation on structured languajes.
A goto is perfect for some weird situations. Imagine your fiancee calls you at work, because you've won severals milions on LOTO. May be your exit from work will be no too structured, and so must be.
In others words goto deals well with some fatal error situatios, a glance at linux kernel code shows this.
What? I'm getting seriuous.
goto minibar.
|
|
|
|
|
If you don't think that GOTO is an interesting topic of conversation, try the Duff device.
http://www.lysator.liu.se/c/duffs-device.html[^]
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
"You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
|
|
|
|
|
 I'd never seen that before. Awesome.
|
|
|
|
|
Great page. I laught a lot.
Seriouly talking. It's no easy to find pages with such a level of understanding the compiler works, but for me, fallout in the next case in switch statements without break is great.
“My mother loved children -- she would have given anything if I had been one.”
Grouch Marx.
|
|
|
|
|
altomaltes wrote: your exit from work will be no too structured
That's an interrupt.
|
|
|
|
|
In C++ an exception, there is no return in that subrutine.
The ANSI C equivalent may be a longjump, but this is even worst than a goto.
|
|
|
|
|
It's fine when it's the only tool in the box (very old BASIC, DCL, DOS batch files, etc.), but I've never needed it in languages that support structured programming.
|
|
|
|
|
There is few number of bad developers, like me, thinking the goto is not evil.
Veni, vidi, vici.
|
|
|
|
|
Getting past the denial stage is the first step towards a cure. 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
You know, now I have to use the goto on you... 
Veni, vidi, vici.
|
|
|
|
|
The book, "Classics In Software Engineering" has Dijkstra's excellent paper, "The Case Against The Goto". There was also another paper by another author in that book stating situations where the goto is useful. A goto is worthwhile in some very limited contexts.
I found a related very short paper by Dijkstra online that is titled, "A Card Against The Goto" at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html[^]. It is more of a philosophical outlook about the issue and doesn't go into the depth of the article in the book.
It's also worthwhile reading the paragraphs under "Considered Harmful" at http://blogs.perl.org/users/erez_schatz/2011/07/rewriting-the-language.html[^]. That section tells about how when Dijkstra's article, "The Case Against The Goto" was submitted to the ACM magazine, the editor changed the title [to "Gotos Considered Harmful"] and created a furor! Two key sentences at the link above are:
"It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist."
However, it is true that, in the vast majority of cases, using a goto can and should be avoided. But it's also a mistake to revile any code that contains a goto merely because the code contains one.
By the way, I also agree with another poster that multiple returns in a function are undesirable, although I can see exceptions for this too. A single return in a function makes debugging so much easier. I make a serious effort to have only a single return, however, I have broken this guideline at times, particularly when working on critical legacy code where I wanted to minimize changes to the code.
Here's a construct in pseudo-code that I've used in both C and C++ programs to avoid the need for gotos for multiple error cases. (By the way, I also always put the parenthesis in a statement, even for only one-line statements, because it makes the code easier to maintain. Typically, 85% of the cost, or time, spent on code is maintenance, so typically, code should be written to make it easy to maintain, as opposed to making it easy for the person writing the code).
I did not invent this technique and I don't know who to credit for this idea.
do
{
if (error)
{
break;
}
if (error)
{
break;
}
if (error)
{
break;
}
}
while (false);
That construct avoids the extreme indenting that can occur with a lot of nested error checks. Each 'break' statement acts like a goto that sends control to the first statement following the end of the do loop. And, of course, it's not really a loop at all because of the "while (false)" at the end. I believe that most compilers will optimize the loop away.
modified 10-Nov-13 12:51pm.
|
|
|
|
|
I prefer:
if (!error)
{
if (!error)
{
if (!error)
{
}
}
}
No "do...while" required.
This also has the advantage that excessive indenting reminds the programmer that they need to break the code out into method calls to simplify the layout. Once it gets past four or five indents this becomes obvious.
Better would be:
if (error)
{
}
else
{
if (error)
{
}
else
{
if (error)
{
}
else
{
}
}
}
This way each error can be reported as necessary, perhaps with some cleanup or roll-back code.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
