The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I've not used the goto keyword in any of my C/C++/C# code over the last 20 years or so.
I routinely use break (goto's more civilized brother, as it were) to exit for loops early. I do this in cases where expressing the iteration as a for loop is more appropriate for the general case, and the break handles the exceptions. I don't tend to use continue nearly as much in similar situations; I'm not sure why.
I dislike when code uses exceptions as an exotic form of iteration/flow control. My least favorite mechanism would have to be setjmp()/longjmp(), which is a very old C runtime library mechanism that fortunately doesn't see a lot of use today.
Yup, been there. Just after starting my first "real" job in the early PC days (company upgraded the network file server to a bleeding-edge IBM AT just after I started), I had to debug a DOS BASIC program that implemented the equivalent of function/subroutine calls by saving the return line in a variable (all global, single letter optionally followed by a single digit), setting an ON ERROR GOTO for the desired function, then forcing an exception, and using the same mechanism with the saved return line value to return. Written by a nuclear physicist, no REMarks in the code - just the physicist's hand-scrawled notes. I might be mistaken, but I seem to recall that there was a way to set the ON ERROR GOTO for different target lines depending on the exception code generated, and this was used to pick which "function" to "call" at various locations in the code.
Today, he probably would have coded the entire thing as a single Excel macro with just Row-Column cell references and of course, no labels, headings, etc.
I think it depends on the context. In C it's not so bad and I can think of a few notable examples where it is used. One instance I found rather humorous and posted in a coding 'hall of fame' page we used to have here, is in the default procedure of Windows v3.0 and the label used was "IcantBelieveIactuallyUsedAgoto." The source code of it was published in an old book by Peter Norton on windows programming.
On the other hand, I think using goto in C++ is a really bad idea. Since objects are automatically deleted when they fall out of scope, a goto could result in memory leaks if not used very carefully. As far as I am concerned this opinion is not based on fear nor is it irrational. YMMV.
Back in 1988 when I went to university to study computer science we were taught that we were never
to use goto except in one particular circumstance with COBOL.
We were strictly taught structured programming and in the first year had 2 hours of computer time each week. Most of our work was done on paper.
Fast forward to now and I am quite happy to use a return statement in code which in essence is a goto.
I think in principle it's good to learn the rules of structured programming to know when it is ok to break those rules.
“That which can be asserted without evidence, can be dismissed without evidence.”
the first year had 2 hours of computer time each week. Most of our work was done on paper.
I remember those days well!...being a CS major from around '87 to '89 when my part-time afternoon job turned into full-time, which meant almost no lab time. I quit school for 10 years and finally went back and finished. During my 10 year hiatus, I had very little contact with computers so coming back to it after a decade I was more than a little pleased to find that I could finally do homework at home...even in the wee hours of the morning!
Somewhere in a box, in a closet, are notebooks with handwritten C, Pascal, and Fortran homework assignments. I also have some greenbar printouts with notes/grade. Deliverables for an assignment were typically handwritten pseudo-code and/or flowchart and the printout which contained source code and results. That junk probably won't make the next move!
It amazes me now to think about how different it was to learn programming back then. Nowadays, an answer to a question is usually just a few clicks away, back then we relied on books, our own wits, and occasionally teachers/aides who sometimes knew little more than we did.
I am ambivalent as to whether I would rather learn CS now or back in the 80's.
Back in the 80's there was no WWW or everything that came with it(given the internet did exist with JANET being the network we had access to).
In some ways I think people have it harder nowadays because there is so much more to learn.
On the other hand a kid with a laptop and network connection can easily educate themselves, to the same level I was at when I graduated, before they even start their course in CS.
I think we expect more of graduates nowadays than we did back in the 90's when it was a given that your first few years would be on the job training and you understood that when you graduated that you basically knew very little.
“That which can be asserted without evidence, can be dismissed without evidence.”
For several years programmers have had OOAD and OOP pounded into their heads, and goto is an inherently structured code construct. If you use goto in an object oriented program, you are creating spaghetti code, which is why that particular reflex exists.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
It's not an irrational fear: it's a sensible precaution. goto is a "shortcut" for lazy lecturers and lazy students - it positively encourages poor quality code and bad habits. That doesn't mean it shouldn't be used, just that you have to understand why you aren't using it before you should be allowed to use it. It has its place (try doing assembly code, or time critical embedded C / C++ without it) but generally speaking it's a bad idea in "modern" languages which have rich flow control constructs and a set of good practices which should mean that it isn't that necessary. For example, I've been coding in C# for nine years now, and not once have I needed to use a goto, nor have I had to "fudge round" not using one.
It annoys me when it's taught early because the idiot running the course can't be bothered to teach a while, for, or foreach loop to beginners. Because once you start using a hammer, every problem looks like a nail...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
Are we asking annoying questions, just for the sake of asking?
No, not just for the sake of asking, just for the sake of annoying.
Also to see how many mind readers would jump on me for using them - even though I didn't say I used them. And don't, except in rare, low-level performance cases.
It came out of a recent discussion. I was reviewing some code someone showed me (they didn't write it) that had a goto in it. He said the code was Spaghetti Code. When I asked why, he said because it had a goto. I asked why that made it spaghetti, and all he could come up with was that he was taught that. I asked about a few other "programming truths", and had much the same response. This is good, that is bad, but I don't really know why. I started thinking about how for some things, aspects of programming have become more faith than science.
That's not relevant to me, you're implying they may not be bad.
This is good, that is bad, but I don't really know why. I started thinking about how for some things, aspects of programming have become more faith than science.
No, it hasn't. We have simple rules for the monkeys to follow; anyone who can actually think doesn't need them. So we can't do without that faith, since some people continously ignore everything in the manual.
While I agree that a single goto won't kill anyone, I also haven't seen any practical C# example where using one would be justified.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
As with any instruction in any language, improper use will get you into trouble. There are some 470,000 words in Webster's dictionary. Day-to-day we typically use less than 500. The others are there just in case but that doesn't mean we have to use them. The closer to bare metal you get, the more the higher level languages simply carry too much overhead to be practical. In resource-constrained environments you don't have the luxury of being elegant. On a 32K platform you're limited to about 3-5,000 lines of (C) code, you need to be creative and shortcuts save program space. When the need arises for an assembly stub, branches and jumps (assembly level GOTOs) are a way of life.
The GOTO instruction is a tool and like any tool, use it if you need it, but don't use it just because it's there. As it is said, if the only tool in your box is a hammer, you're constrained to build everything with nails, but if you need to nail something, it's useful (not necessary) to have a hammer.
Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful". Communications of the ACM (PDF). 11 (3): 147–148. doi:10.1145/362929.362947. The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. ... The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program.
The problem with goto is it makes it trivially easy to write spaghetti code. It is also the one of few jump methods available to a computer, so once you get down to the hardware goto (jmp) can be found nearly everywhere.
On the other hand, you can write spaghetti code in any language, even those without goto, simply by not factoring any control structures properly.
goto overuse makes it very difficult to understand and debug a program. There are legitmate uses of goto, such as breaking out of a loop, but in those cases I would just use the keywords that do the same thing for clarity. I had the joy to try and debug someone's code that was riddled with gotos. He also had the nasty habit of making functions several hundred lines long. I ended up just rewriting everything he wrote. I still feel that was the correct decision, and it only took me a couple days.
Last Visit: 31-Dec-99 19:00 Last Update: 20-Jan-21 12:40