This kind of depends on your language: Having cut my teeth in C, I know that
for(initialize, modify loop variable, evaluate loop variable) is the same as
initialize
while(evaluate loop variable){
code
modify loop variable
}
I asked an instructor for permission to take an assembly language course when my formal background was limited to self instruction and some microprocessor courses. I failed the question "What is a for loop?" when I told him it was a while loop with extra bookkeeping. They were using Pascal in entry level course, where a for was essentially a counting loop. Complained to the Dean, and got into the course. Of course, there is the for(each element in : set{}) type of loop, yet another animal.

Had another question in a class - What is the most important structured programming construct? My answer - the if and goto, because you can make any of the other structures with these two statements (the way it is done at the assembly level). Just takes some discipline.

Misusing them results in reduced code clarity, and that's a Bad Thing.

Knowing assembler is useful. It helps when figuring out why certain things are happening, but to use that as the basis for writing higher level languages is not good. You need to stop thinking about what's going on under the hood to some extent, especially if that results in you writing anything involving a goto...:)

I am not suggesting writing code that way, merely trying to raise some points for the sake of discussion. C is notorious for obscure code. You can use a C for code to write a while loop be using comparisons and updates of loop variables that don't involve counters. That's no better.

That said, I have seen authors state that using a goto to exit a complex decision structture can be appropriate, as long as you go only to the end of the enclosing structure without entering another control structure. It can simplify the code (make it more readable, simpler to understand), and will confess that I've done it.

I've seen too much code with multiple returns in the same function. IMHO, this is a greater violation of the stuctured code principle of one entrance, one exit. I've been bitten when I didn't do all the clean up code on all exits of some else's code, and rewrote the code to avoid the situation.

I am not suggesting writing code that way, merely trying to raise some points for the sake of discussion. C is notorious for obscure code. You can use a C for code to write a while loop be using comparisons and updates of loop variables that don't involve counters. That's no better.

Obscure code in any language these days is a bad thing, frankly. Obscurity is the bane of maintainability.

Originally Posted by rdtindsm

That said, I have seen authors state that using a goto to exit a complex decision structture can be appropriate, as long as you go only to the end of the enclosing structure without entering another control structure. It can simplify the code (make it more readable, simpler to understand), and will confess that I've done it.

Doesn't make them right. Decision structures in an OO environment do not require the use of explicit gotos to make them readable. If you find that a goto makes something more intelligible then the odds are that you've written it badly in the first place.

Originally Posted by rdtindsm

I've seen too much code with multiple returns in the same function. IMHO, this is a greater violation of the stuctured code principle of one entrance, one exit. I've been bitten when I didn't do all the clean up code on all exits of some else's code, and rewrote the code to avoid the situation.

Multiple returns are not a problem in many instances. They are, in fact, a lot easier on readability and maintainability (again in many instances).

In long methods with a bunch of nesting they can cause confusion, however I would argue that it is far more likely that you've written a method that is doing too much and ought to look at reworking that code rather than falling back on deep nesting and flags.