|
CDP1802 wrote: Thinking and making most of the resources at your disposal is more important than blindly following rules.
Well said. My thoughts exactly. It's a matter of the right tool for the job. This is true in any field of endeavor. You use a spoon when you need one and a front-end loader when you need one of those. You don't just say "never use a spoon" once you've discovered that you have a front-end loader at your disposal. You use whichever one suits the job at hand.
GOTO makes sense in a lot of contexts, in others it doesn't. Whatever construct allows you to express the idea in code most elegantly is what you use.
I have to laugh at the religious fervor that develops over this particular subject.
-Max
|
|
|
|
|
CodeBubba wrote: GOTO makes sense in a lot of contexts, in others it doesn't. Whatever construct
allows you to express the idea in code most elegantly is what you
use.
I have to laugh at the religious fervor that develops over
this particular subject.
It's not religious fervor; it's the voice of victims of the GoTo Holocaust saying "Never again!" I speak for myself and many, many others who had to maintain code written in structured languages by programmers who didn't care to structure their code. At the time I entered programming as a profession, Dykstra's "GoTo Considered Harmful" had been published for over a decade yet many programmers still disdained use of structures even after moving to languages like C which supported a rich set of control and loop structures. This was called "job security" - after all, if only the original programmer could explain his code, obviously he needed to be kept happy, and the less readable the code was the better it served the programmer's purpose.
The biggest problem with GoTo is that is does NOT "express an idea"; it just tells you where to go next. Thus, while the code implements the algorithm, it does not express it to the reader.
That hasn't kept me from occasionally letting a goto remain somewhere where it would have been too time-consuming to factor it out. Also, goto is vital in one particular context: when otherwise code would be too large for the available memory space. Before virtual memory (i.e. the days of MSDOS) I helped maintain multi-megabyte programs loaded 256k at a time into the PC's memory, and gotos could sometimes eliminate code repetition in complex algorithms that resisted refactoring (e.g. they worked, but no one really knew how). So, I do know that gotos are sometimes necessary.
However, it is my considered opinion based on years of experience maintaining code with gotos along with years of experience first using structured programming then other forms (functional, declarative, later OOP) that if goto isn't absolutely required to solve the problem, then it is a maintenance menace because it does not express anything, requiring a programmer to parse the branches in order to understand the algorithm being expressed. This may not seem like anything to someone who routinely uses gotos, especially if you work within a group that shares the same habits and code styles, but do you remember how long it took to become an expert at what someone else's code would produce? (If your answer is "not long at all", I suggest you've never worked on anything that I would call complex). Maintenance of code in a business environment means you have to train your fellows in what you do, so if a truck turns you into a greasepot on the highway your business fails to fail because the next guy can take up approximately where you left off. I've got MSCS-level algorithms that give my partner in crime headaches, and they are all nicely structured code encapsulated in sensible objects, AND he's got a graduate degree in a real engineering discipline (thus, he's not a slouch) - I could have used a goto here and there to shorten code length, but how long would it take to explain what that's doing when he's struggling with the rest of the logic?
To anyone who has shared my experience, saying that "GOTO makes sense in a lot of contexts" suggests you "know" things that just aren't true. Show us where you thinks it makes sense, please. Who knows, after all this time I might just learn something new.
|
|
|
|
|
You may not have meant it but your tone is sanctimonious. If that's the way you intend it, it's not appreciated.
No doubt, I have (over 35 years) cleaned up a lot of messes (spaghetti code) where GOTO was misused. When I say "a lot of contexts" I mean I have run into a lot of situations in existing code where its use still makes sense and where "factoring it out" isn't profitable.
I practically never use it any more in my OO style code however, as it was pointed out earlier I believe, there are still situations (assembly code, etc) where it's use is appropriate.
I repeat: use the right tool for the job. If a developer is incompetent then GOTO will not be his only abuse.
-Max 
|
|
|
|
|
CodeBubba wrote: OTO makes sense in a lot of contexts, in others it doesn't.
I doubt that in the general sense and specifically for this site/forum.
It could be that there is a problem domain like camera firmware where the context basically requires goto.
However in the context of standard enterprise business development that is done in languages like Java, C# and/or C++ it almost never is needed.
|
|
|
|
|
When I was a professional Systemprogrammer (Assembler)we were fighting against branches whereever. This because the instruction prefetch which fails when you go out of the straigt forward. Also todays machines do that prefetching and will fail to guess the thread! So avoid going left or right - go straight on.
Jordi
|
|
|
|
|
You have to be pretty ancient to appreciate the goto controversy. I was writing FORTRAN in the mid-sixties and my oh-so-clever programs were an unreadable tangle opf goto's and labels. My initial response to Dijkstra's letter was "program without goto - impossible!". But I soon saw the need for sensible control structures.
Also, I see goto-restriction as a high-level language issue. I have never hesitated to use goto (or equivalent) instructions in assembly-language programming - often because there's nothing else. But knowing high-level control structures certainly improved my assembly style.
|
|
|
|
|
That sounds like one of my first text-based QuickBasic programs. It was a Tony Hawk menu (to store info about the game, such as cheat codes and areas that were good to get high scores).
Ah, those were the days. A shame I didn't backup the program. Pretty sure it was lost forever when the computer it was on was engulfed in flames from a garage fire my cousin accidentally set.
On second thought, probably best all evidence I ever wrote that was destroyed.
|
|
|
|
|
No, it's always a pity when something like that gets lost. Last year I found my first complete little game. It was written in CHIP-8[^]. I remember that I modified the CHIP-8 VM to relocate the video buffer and some machine language routines outside its tiny 4k address space to free as much memory as possible for the program and the graphics.
My old computer still loaded the tape and I have converted it to binary on my PC. It is now included in an emulator for those old computers. You have made me download the emulator and I have just landed on the moon (in glorious 64 x 32 pixel resolution). Want a screenshot? Here it is![^]
I'm invincible, I can't be vinced
|
|
|
|
|
Looks pretty amazing! Now I want my old Tony Hawk program. 
|
|
|
|
|
Can't be changed, but tomorrow I will turn on the old computer again and search through the tapes for some more old creations 
I remember that there at least was my clone of Asteroids and a Star Wars game where you had to attack those big ATATs. The last one actually used a 'sound card' I had soldered together with an analog sound chip I had pulled out of a broken toy. The same one that's lying on my desk before my keyboard. I have removed it because of the dangerous D/A conversion which could have fried my old computer in no time (but fortunately did not)
I'm invincible, I can't be vinced
|
|
|
|
|
andrewgissing wrote: An abstracted goto !
A switch statement in disguise
|
|
|
|
|
Exactly.
var state = 0;
while(state != 5)
{
switch (state)
{
case 0:
state = 1;
break;
}
}
Interestingly enough C# turns a switch into a set of gotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.
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)
|
|
|
|
|
Jonathan C Dickinson wrote: Interestingly enough C# turns a switch into a set of gotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.
That only happens when dealing with string cases (above some point 3 or 5 IIRC). All others use a jump table.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
