function foo {

var1 = allocate_stuff();
result = 0;
if ( !next_foo(bar)) {
  cleanup_1();
} else {
  result = do_the_right_thing(bar);
}
return result
}

and i should admit that i am offering *3* tight functions to replace one messy one, which is a less clear advantage, but in my book, still quite preferable.

`function foo {

var1 = allocate_stuff();
if ( !next_foo(bar)) {
cleanup_1();
return 0;
}
return do_the_right_thing(bar);
}

and do the inner stuff in the next_foo function.

now i can already see that this doesn’t pass all the state in to the second function,
but seriously… do you want to maintain the giant mess of code that is one function
where everything is passed implicitly from the parent scope? i didn’t think so.

if next_foo depends on var1, then next_foo(bar,var1) it makes it clear that the remainder depends on var1. much nicer, and next_foo will be clear.

i’m sorry, but your argument that the second version looks ok now, but if it was a giant mess, it would be messy, just doesn’t ring true. If the function was a mess, then you’ve got too much going on in one function… and breaking out goto isn’t gonna make that turd any shinier.

In your version of the big messy function the creation and cleanup of thing1 are like miles apart, on opposite ends of a giant mess, connected by a goto… ick.

compare that with my version, a small tight function, which creates something, has calls out to “try_to_continue” (next_foo) and cleans up if that fails.

error handling

instead of goto

“The classics are books everyone has heard of but noone has read”

seems apt.

What do you think a while loop does, if not a “hidden” goto:

while( condition() ) {
do_this();
}

/* versus: */

do_this_loop:
if ( condition() ) {
do_this();
goto do_this_loop;
}

If you’re gonna bitch about gotos, isn’t it hypocritical and completely “head in the sand”-ish to use while loops? Why are you using processors with JMP instructions? Please show me this new computer of yours that works differently.

Assuming you choose a good label name, don’t gotos better promote “self-documenting code” ?

Jussi JumppanenNo Gravatar Says:
April 27th, 2009 at 08:26

In most cases code can be restructured to not require the uses of a goto statement.

Jussi: Why? Why do *you* think goto is bad and that is necessary?
Because other people told you it is bad?

Pádraig BradyNo Gravatar Says:
April 27th, 2009 at 10:33

Note for the common case of a common cleanup, one can:

Pádraig: I fail to see how this is any clearer, and it is harder to decipher what is really going on. Again, no justification given to why one would want to do this.

qNo Gravatar Says:
April 29th, 2009 at 09:19

If your code is to be MISRA compliant, must pass a pretty severe QA-C test, and needs 100% test coverage on all decisions in your code, you better not use goto, or multiple returns (a.o.)

If whatever tool(s) you use can’t determine when all the paths in your code are taken when you use gotos or multiple returns(), isn’t that more a problem of the tool you are using, or maybe the fact you are using C when you should be using something else?
Why can’t that tool “parse” or work with valid C code?

I realize limiting yourself to a subset of C is a very good thing in certain cases, especially in regards to “proving” things about code.

Are you saying you *would* use multiple returns and gotos on code that did not need to be ran against those particular tools / QA processes?

My understanding is the QA and test coverage is a job requirement, but that makes your argument less valid to me — you are only against goto because your job won’t let you use them.

I am in favor of multiple return statements. If you know the “answer” to a function, why dilly-dally, instead of return it immediately, as soon as you know?

Sure, you can use nested ifs, but that makes for hairy hard-to-follow code, and huge indention leads to things not fitting on a single screen (whether vertically or horizontally) of your editor.

Comments? I hope my self-righteous tone is enough for some posters here to realize theirs. Do some people really expect we should believe them because their name is attached? Or someone else said so? And nary a word of *why* they feel the way they do, and what brought them there?

Yeah, I like to debate about things that might not matter, but if you didn’t want a debate, why did you post on this topic? Or why did you post on a topic you don’t care about?

I am not the perfect person or coder by far. But I think a good person is thinking for themselves and not repeating what they are told, *especially* when it comes from the “mouths of the gods”, be it coding or whatever.

(yes, I will take some chill pills).

Sorry, I can only hope Djikstra had good intentions and would have been happy his message “got out” eventually. But I also hope he would have utter shock and disbelief at how many people swallow it now w/out a second thought.

“To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.”

I’m pretty damn glad they exist .

If your code is to be MISRA compliant, must pass a pretty severe QA-C test, and needs 100% test coverage on all decisions in your code, you better not use goto, or multiple returns (a.o.)

About that “judiciously using a construct”, I understand you. But do also know that consistency has to be taken in account.

For Christ’s sake, what am I arguing here? What will be defended next? Basica rules?

* one point of entry in a block of code
* and one point of entry out.

As well as goto’s, the following violates this idea

* multiple returns
* expection handling
* breaks
* continue

In the author’s examples, there is one point of entry into the function and one point of entry out. His goto’s stay within the function.

Oh, if you’re avoiding goto and multiple returns because of Dijkstra’s “goto considered harmful”, then you’d better stop using exceptions too — they violate his structural rules.

A do/while with breaks to jump to a cleanup section is a dirty hack to avoid using goto. It keeps the structuralists happy because it doesn’t technically violate their rules, but it is _more dangerous_ than goto. Didn’t know that, did you? The C standard does not define semantics for break/continue in nested loops, so you cannot (safely, across compilers) use looping constructs within your error handling do/while construct.

Fortunately Knuth (who unlike Dijkstra DID program) wrote “Structured Programming with Goto Statements” and dispelled the idea that goto is always bad … or at least he would have if people could grasp the idea of not pushing Dijkstra’s goto myth all the time …

(I don’t even like exceptions that much.. – I guess I’m a bit sick.)