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.
The important thing with goto is knowing when not to use it - which is most of the time.
Goto has its place, but if you can use a structured loop or branch instead then your code is generally cleaner and more maintainable. But very occasionally, using a goto makes your code cleaner or much more efficient and (provided it's well documented) isn't a problem.
It's a problem when it's used because they can: and teachers who introduce it early should be hung, drawn, and quartered (and I don't mean "well hung", "sketched", and "given an apartment").
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
The only time "goto" is warranted is if in a nested structure where to accomplish the code control, a flag would need to be set and then checked more than once by the control statements within which this decision to break out is needed.
I think I have used it 3 times, and all times, I gave a very good comment as to why it was the proper choice.
goto is NOT the enemy, it's only when it's used wrongly.
... contrary to popular belief disguising it fixes nothing
... if you really need to GOTO, just do it - hiding it only increases the bullshit level.
unfortunatelly, there are teachers that tell the kids "GOTO is bad," but then "to do the same thing..." they then go on and teach the kids how to disguise them, i.e. instead use THROW, or stick the [inner] code in a method and return early (i.e. still in an indefinite state). ffs, really!
I've got no problems with goto,
but I do have issues with (1) sh*t code, and even more (2) attempts to hide sh*t code
Well said! Not using GOTO has become a matter of faith rather than good programming practice. I've seen some totally impenetrable code that has a indeterminate state, all because of the convoluted efforts the devs went through to avoid a GOTO. (Including rafts of local variables called things like a, aa, aaa, aaaa, x, xx, xxx, xxxx etc!)
GOTO is just another tool - it can be used appropriately or badly, just like any other...
teachers who introduce it early should be hung, drawn, and quartered (and I don't mean "well hung", "sketched", and "given an apartment").
My CS teacher introduced them early. However it was more of a "Here is the goto statement, here is how it can go horribly wrong, and that is why you should never use it again... ever. If you do, you will fail whatever assignment it was in." sort of way.
While it was a bit over dramatic, she did follow up with how to better handle branching/looping logic without them.
A lot of these prohibitions are in reality "almost never do such and such." But at the end of the day, other things being equal, it's all about clarity and readability and there will be cases where it's fine. The language directive does exist after all (when it does).
Years ago I recall reading a section in the book Code Complete by Steve McConnell where he presented some code using goto and stats showed that almost no developers were able to rewrite it correctly without the goto.
I was going to chime in that all Exception handling is really goto programming and then I saw DRHuff's excellent reply.
People talk about never using goto and then you look at their code and see exception handling and think, "what's this here?"
This is also why exception handling can be a pain in the arse. All that jumping around.
Consider what happens if you throw an exception in your catch block -- and it is possible. Things can get really ugly jumping here, bouncing there.
I think the only time that exception handling should be used is when the current code section does not have any control over the code that is throwing the exception - i.e., it is preferable to check and control something than to rely on an exception that simply does a goto the catch branch.
I had the misfortune of having to deal with an automation systems framework that was essentially a state machine library and it changed states by throwing an exception. I thought it was incredibly stupid. This framework was spreading throughout one division of a customer until someone finally pulled their head out and asked what is this pile you have subjected us to?
This particular customer joined my very short list of the worst ones I have ever dealt with and I refuse to buy any of their products to this day.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
agreed. I'm thinking of calls to another library where it throws a specific exception after being configured properly. In that case all inputs are set to valid values but then something happens which causes the exception - network not available or something.
And what happens when the language you are programing in offers no try-catch-throw?
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I don't know who you are. I don't know what you want, but I have a very particular lack of skills. I will never be able to find you. But what I do have is two dollars and a Casio wristwatch. You can have one of them.