Daniel, I agree that nested if structures are appropriate for some situations. However, a typical pattern is to check for fatal errors at the beginning of a function, and I prefer not have my entire implementation within a giant if clause. If I understand what you’re describing, I think that mid-implementation cleanup code could be accommodated within the goto schema, though of course it depends on the exact nature of the code. To clarify, I am advocating a single exit point rather than multiple goto destinations.

Another advantage I see with goto statements is that if you customize the labels according to the function, e.g., returnFromDoSomethingWithArgument:, then at any time you can perform a project search and immediately find not only the end of the function but all of the exit conditions for the function as well.

Lars, the label could appear at the same level as the closing brace, unindented. Another approach would be to use boldface, color, or comments to highlight the label. In any case, the label would always go near the end of the function.

Hear, hear! I wish more programmers would take this sentence to heart!

Among the books[1] I read for my software development, two of the more important ones had nothing to do with programming at all – instead they covered the ins and outs of text design and layout. Reading them gave me an appreciation for how much information can be conveyed by the mere arrangement of text elements. Since then, I try to make the code I write to pass the squint test: if I squint my eyes so that the individual letters would blur into a gray blobs, coud I still make out the control flow of my program. If not, I did something wrong (for example the goto example would fail the test as the goto label is too far indented for its possible uses).

[1] Since I’m not paid for it, I might as well mention one of them: Robin Williams “The Non-Designer’s Design Book”.

And the * always goes next to the identifier, not the type:
int *x, *y;

Too many of these () is a waste of my time and yours trying to figure out what is going on. One or two extra for things like (a & b) && (c & d) for those times when you can’t recall what happens first.

Goto:
How about:
if (something bad)
return kFailure;
if (something else bad)
return kAnotherError;

// good code goes here

return kAllGood;

You might think that you could introduce parentheses to clarify this: int (*array)[50]. But C (or at least GCC) gets this backwards: That gets you a pointer to an array, not an array of pointers. The parenthesized code for what you wanted is int *(array[50]), which of course reads the other way (as a pointer to an array).

I suppose this is one reason why people don’t parenthesize their declarations.