|
Ah, a bit like GOTO DEPENDING
[/Misty-eyed nostalgia for COBOL]
|
|
|
|
|
Actually switch is translated into a bunch of "if" statements.
|
|
|
|
|
/trollattempt?
See: Leppie's comment.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
First, the person missed the idea/point. The person should have used a "while" loop instead.
|
|
|
|
|
|
I would also group the break keyword with goto:
public static void renameSchedule(string currentName, string newName)
{
foreach (schedule sched in Schedules.lst)
{
if (sched.scheduleName.Trim().ToUpper() == currentName.Trim().ToUpper())
{
sched.scheduleName = newName;
break;
}
}
}
After all it is jumping out of the looping logic - I use this a lot...
I was taught never to use a goto at university, probably because it would mess up all those nicely drawn diagrams we were creating before we wrote any code, then in the final year when we were doing advanced(cough cough) COBOL programming we were told that there was one instance where we could use it...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's true that break (and continue) are very similar to goto. However, it's also very restricted in scope, and it cannot jump backwards. It cannot jump into the midst of a loop either. That makes it less likely to accidentally break code.
I'm not saying it's good, but it's not quite as bad as goto can be.
|
|
|
|
|
The good old goto debate. A goto is a bit like telling the computer that I don't want you to proceed to the next line of code, instead make some other line the next thing to execute. And we do that all the time: exit for, exit do, if some condition goto next line otherwise goto some other line. While some condition go into first line of loop block otherwise goto past the end of the loop block. And then, it all eventually becomes machine code / opcodes, and all of these become some kind of jump instruction, which is basically a goto. So for all you people out there that think that your code has no gotos, I can assure you the CPU is doing jump instructions left, right and centre as YOUR code runs in the CPU. Now please don't tell me that your code is somehow bypassing the CPU.
The reason this myth exists is that those early versions of BASIC had line numbers for each statement. And you would code "GOTO 760". Problem was when you inserted lines and made 760 line 761 or whatever but didn't go and update everything pointing to 760. And so this caused problems and bugs. Let's move on. We have alphabetic statement labels (used all the time in assembly language by the way), so you can now "Goto SomeLabelThatHasAMeaningfulNameThatWontBeRenumbered" and the problem is gone. Use goto freely, it's OK. I do it. It gets me out of deep nested rules and condition logic where I have established something I needed to establish. Yes there are always other ways to achieve the same result, but no - they are not always better or more elegant. And now it is time for me to go to bed.
|
|
|
|
|
Umm, as you said goto caused problems if you used it and didn't really know how it worked. The thing is most (if not all) programs are compiled and this causes the assembler to move all the loops, functions anything else to the old loveable JMP or Jump statement (which is a go to this location). (Complains about "Softies not know how work things", burn hand on soldering iron!)
|
|
|
|
|
The reason not to use goto is not a technical one, but a code cleanliness one. A goto is an unstructured jump and makes it much harder for a human brain to comprehend the structure of the procedure. Loops with breaks and continues, conditionals, switch blocks and so on may translate to jump instructions in assembler or IL, but they're structured and therefore easier to understand.
The only time I would say it might be okay is the 'double break' (i.e. breaking out of a 2D or deeper loop set). When your logic is this complex it's usually better to take the looping code out into a sub-procedure or -function and use return instead, because chances are that procedure is too long already. (You can always ask the compiler to inline it if you think the function stack is critical.) In modern languages, proper error condition handling (i.e. exceptions) have taken away most of the situations in which you'd want to do this.
So I agree up to a point: fundamentalist 'never' dictums (dicta?) are not particularly helpful. But it is very rarely the most elegant approach to use a goto.
|
|
|
|
|
The most common argument I hear from experienced programmers is that a goto is a convenient way to jump around in an eight level nested loop.
This tells me they have mastered the function call yet.
But I can see how gotos can make it easier to navigate spaghetti code.
|
|
|
|
|
The point I was making was: use Goto when it is good to do so. That's a matter of judgement. It probably won't be often. But use it freely when you consider that it works well - when it simplifies or clarifies the logic flow. Don't be religious about following some rule that you heard somewhere. "Shoulds", "don'ts" and "nevers" are a poor substitute for judgement.
The fool knows the answer, the wise man thinks.
|
|
|
|
|
This is a simplistic example of the sort of thing I am talking about. My sympathies to those of you who find it un-structured, hard to understand, un-clean or bad code. Let me see yours.
if WageEarner then
WeeklyPay = HrsWorked * Rate
Goto WklyPayDetermined
end if
if SalaryEearner then
WeeklyPay = (Salary * 7) / 365
Goto WklyPayDetermined
end if
if FutureHire then
WeeklyPay = 0
Goto WklyPayDetermined
end if
if Retired then
if WasWageEarner then
WeeklyPay = FinalRate * 40 * 0.5
Goto WklyPayDetermined
else
WeeklyPay = 0.6 * (Salary * 7) / 365
Goto WklyPayDetermined
end if
end if
WklyPayDetermined:
TaxDeductible = WorkOutTax(WeeklyPay)
CreateBankTransaction(WeeklyPay - TaxDeductible)
|
|
|
|
|
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).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
