|
I've seen justifiable GOTOs in C code. Usually, the scenario involves nested control structures (IFs or loops) and the possibility of a trash-it-all error deep in the nest. C++ offers less of an excuse for GOTOs, because of the ease of use of the exception mechanism.
That having been said, if a programmer feels he can defend his use of a GOTO, and his program is otherwise legible and maintainable, it's usually not worth starting an RWAR over it. That is, unless you enjoy RWARs for their own sake!
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
andrewgissing wrote: Msny years ago
Years before MSN, you mean? 
-= Reelix =-
|
|
|
|
|
The gosub call was the mechanism for calling faux functions / subroutines.
Unlike the goto, the last address was pushed on the stack so the subroutine could return to the location it was called from.
They were a big improvement over goto.
|
|
|
|
|
You should try to rewrite that code with goto statements instead of gosub, and see what you get. 
|
|
|
|
|
Gosubs were used alot in the old days when programming in GWbasic and basica. think the time I used them was in dos 2.11
|
|
|
|
|
Is it better to have a ridiculous number of nested levels of "if" statements? Sometimes the inability of having a goto results in a lengthy "elegant" work-around to avoid nesting purgatory.
|
|
|
|
|
That sounds like a false choice to me.
Do you often find yourself programming a ridiculous number of nested if statements?
I often encounter situations with a lengthy series of if statements. But for those, you execute a short code block and return.
|
|
|
|
|
The original point of limiting goto's was lost almost immediately in COBOL where a goto out of a paragraph that was performed would result in a stack overflow or the more harder to debug no-longer-valid stack entry. This type of goto was discouraged for the proper reasons, namely that the program would fail completely or fail to work properly when mixing performs and goto's in this manner.
In the effort to promote 'structured programming', this message morphed into "no goto's". This was a much simplified version and promotes code reuseability, although it eliminates the very useful goto beginning-of-paragraph and goto exit-paragraph statements.
This 'simplify the message' has carried over to every programming language ever since.
Too bad.
Charlie
|
|
|
|
|
Haters being haters again. Sigh. A little historical context might be helpful here.
If you never programmed in a circa 1980 BASIC, the language did not provide named subroutines or structured control statements, symbolic labels or indentation. GOTO was all you had. To complain about GOTO in a language that has nothing else is just hating. This code implemented a very structured thing, a finite state machine. It was actually best practice for this language that the states were in subroutines and the GOSUBs in the main loop were all together.
Back in the 1960's when many of your moms and dads were children, W Edsgar Dijkstra penned his fameous "GOTO Considered Harmful" article, and Ed Yourdon and others kicked off the "Structured Programming" movement, with its emphasis on single-entry/single-exit programming. (The structured programming movement was a good idea, but it had the same high hype-to-value ratio as Agile does today.) Languages of the day, led by PASCAL, went a little too far, requiring for instance that all functions return out the bottom, so that you often had to use a bit of state to guard if and while statements (WHILE NOT DONE AND ...) so execution would flow down the page and out the end of the function.
People used this as evidence that we did so need GOTO. Then C came along with its break, continue, and return statements and relaxed the rules a bit. There were arguments from the SP folks that these statements were a bad thing, but practitioners won the day.
There were GOTOs to exit code that returned resources. These, said GOTO fans, were evidence that GOTO was unavoidable. This was mostly hogwash, as you could test most resources to see if they'd been allocated, and only return the ones that were. And the arrival of exception handling and the resource-allocation-is-initialization idiom in C++ rendered that discussion moot.
GOTO has few places left to hide. I haven't needed to use a GOTO since 1995, and I have cleaned up many a function by removing GOTOs and fixing up the logic to make it simpler and more correct. I would not miss GOTO if it were removed from C++. It's only there (like many C++ features) for compatibility with old and poorly written C programs.
[pours gasoline on the fire]
|
|
|
|
|
Why use all of those ifs? There is an 'on gosub' statement in a lot of BASIC implementations.
Yep, it sure is a horror.
Just because goto would be better in this instance does not make goto any less of a horror in my opinion.
|
|
|
|
|
My signature line says it all.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
If I'm not sure will compiler will understand goto's replacement better, I prefer goto (never trust any compiler).
|
|
|
|
|
|
Anyone who has been around for a long time may remember that the GOTO-less programming controversy was laid to rest (in FORTRAN anyway) by an article published in the December 1973 issue of Datamation magazine. I kept a copy of that article all these years in my humour file as it proposed solving the problem by eliminating GOTO statements entirely and replacing them with the COME FROM statement. Here is an excerpt from the article entitled "A Linguistic Contribution to GOTO-less Programming" (Thanks to the miracle of the internet, the full article can now be found online at this link: http://www.fortran.com/come_from.html )
---------------------------------------------------------
"This statement causes control to be
transferred to the next statement (the
statement immediately following the
COME FROM) upon completion of the
designated statement.
Example:
10 J = 1
11 COME FROM 20
12 WRITE (6,40) J
STOP
13 COME FROM 10
20 J = J+2
40 FORMAT (I4)
Explanation:
In this example, J is set to I by state-
ment 10. Statement 13 then causes control to
be passed to statement 20, which sets J to 3.
Statement 11 then causes control to be passed
to statement 12, which writes the current value
of J. The STOP statement then terminates the
program."
----------------------------------------------
In all seriousness, I have not had to use a goto statement in all the code I have written since the day that structured FORTRAN replaced FORTRAN IV on our mainframes in the early 80's. And I am including all the languages I have since used up until today: C, C++, PL/1, Java, C#, VB, Lisp, APL, and JavaScript. It is almost always possible to refactor logic that appears to require a goto into an equivalent form that doesn't. If your nesting is too deep, refactor into shorter, more succinct, and readable methods. Modern IDE's make refactoring dead easy and I have made extensive use of refactoring support in Eclipse as well as Visual Studio.
But for any fans of computer history, do yourself a favour and read the entire article at the link above.
Apologies for the Canadian (ie. British) spelling of 'humour' and 'favour'. I know they are somewhat anachronistic today, but that was how I was taught.
|
|
|
|
|
Ok, I lied...I just checked some of my FORTRAN source code written in 1985 and there were a handful of goto statements in 20,000 lines of code. But since FORTRAN, I have not used goto's (to the best of my knowledge 
|
|
|
|
|
Use a real language
Just as a reminder BASIC = BEGINNERS All Purpose Instruction Code
|
|
|
|
|
... stuff like this:
switch (Session["Benutzer_Firma"].ToString())
{
case "ABC":
lblManipulation.Text = "Some text in a label";
break;
case "DEF":
lblManipulation.Text = "Some other text in a label";
break;
case "Default":
lblManipulation.Text = "The default text for the label";
break;
default:
goto case "Default";
break;
}
I just found this in a 9000 line ASP.Net page and the rest of it is not a bit better than this. The only things I have changed are the literal strings because the company was mentioned there several times. Especially the lines with the switch statement and the default case are inspiring.
And am I too harsh if I want to have the 'developer' thrown out of the guild, tarred, feathered and then chased out of the city?
I'm invincible, I can't be vinced
|
|
|
|
|
CDP1802 wrote: And am I too harsh if I want to have the 'developer' thrown out of the guild, tarred, feathered and then chased out of the city?
You missed the troll kick to the nadgers.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Well, the did not do any such thing to him. He is now in charge of quality assurance. And this is not a joke.
I'm invincible, I can't be vinced
|
|
|
|
|
|
|
At least this developer understands "how" to use switch statement syntax. I have had the experience of working on code where the developer clearly didn't understand this construct, or simple loops for that matter. It was commonplace to see the good old if...else approach instead of switch statements where they could be applied.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Wow. You actually found something the good man did right. But believe me, it's of little help. You can see by the 9000 lines in one single .aspx what kind of redundant spaghetti code he likes to produce. He practically tries to do everything with strings (why do they always have to do that?). All the code is written as if nothing can ever go wrong. When one of the abundant exceptions is thrown, it usually is not handled in any way. Here and there he uses try and catch, but only to sweep the errors under the rug and go on as if nothing has happened. This man has never heard of OOP and he uses only static methods, probably because he also never heard anything about classes and instances. Please believe me, the whole thing is a chaotic unmaintainable mess.
I'm invincible, I can't be vinced
|
|
|
|
|
CDP1802 wrote: Here and there he uses try and catch, but only to sweep the errors under the rug and go on as if nothing has happened. This man has never heard of OOP and he uses only static methods, probably because he also never heard anything about classes and instances.
I'm thinking we know the same developer here.
I figure that if you are a professional developer for more than 1 year you will run into code like this and know a developer who likes to make spaghetti.
CDP1802 wrote: Please believe me, the whole thing is a chaotic unmaintainable mess.
You're preaching to the choir here. I totally agree that it would be.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Our intern is a beginner. He makes mistakes, but he also is a smart young guy and really interested in learning. He makes progress and one day will be a good man in any team. I hope he does not read this
The fellow who wrote this stuff here has produced several websites, one more horrible than the next. There is no sign of learning at all. The first application of his we replaced was so bad that we wanted to post the complete source of it in this forum or publish it as a book (with critical annotations). In a way I pity him. Having to work without obviously knowing what he was doing and having to deliver something that at least appears to work on time must have been a nightmare. And every time I have to keep his stuff working without getting to replace it altogether I swear to drown him in the river should he ever cross my path.
I'm invincible, I can't be vinced
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
