Continue Considered Harmful? [closed]

问题:

Should developers avoid using continue in C# or its equivalent in other languages to force the next iteration of a loop? Would arguments for or against overlap with arguments about Goto?

回答1:

I think there should be more use of continue!

Too often I come across code like:

for (...)
{
   if (!cond1)
   {
      if (!cond2)
      {
          ... highly indented lines ...
      }
   }
}

instead of

for (...)
{
   if (cond1 || cond2)
   {
      continue;
   }

   ...
}

Use it to make the code more readable!

回答2:

Is continue any more harmful than, say, break?

If anything, in the majority of cases where I encounter/use it, I find it makes code clearer and less spaghetti-like.

回答3:

You can write good code with or without continue and you can write bad code with or without continue.

There probably is some overlap with arguments about goto, but as far as I'm concerned the use of continue is equivalent to using break statements (in loops) or return statement from anywhere in a method body - if used correctly it can simplify the code (less likely to contain bugs, easier to maintain).

回答4:

There are not harmful keywords. There's only harmful uses of them.

Goto is not harmful per se, neither is continue. They need to be used carefully, that's all.

回答5:

If continue is causing a problem with readability, then chances are you have other problems. For example, massive amounts of code inside a for loop. If you have to write large for loops, I would try to stick to using continue close to the top of the for loop. Otherwise, a continue buried deep in the middle of a for loop can easily be missed.

回答6:

I like to use continue at the beginning of loops for handling simple if conditions.

To me it makes the code more readable since there is not extra nesting and you can see that I have explicitly dealt with these cases.

Is this the same reason that I would use a goto? Perhaps. I do use them for readability at times and to stop the nesting of code but I usually use them more for cleanup/error handling.

回答7:

I'd say: "it depends".

If you have reasonably small loop code (where you can see the whole loop-code without scrolling) its usually ok to use a continue.

However, if the loops body is large (for example due to a big switch), and there is some followup code (say below the switch), you may easily introduce bugs by adding a continue and thus skipping over that code sometimes. I have encountered this in the heart of a bytecode interpreter, where some instrumentation code was sometimes not executed due to a continue in some case-branches.

This might be a somewhat artificially constructed case, but I generally try to avoid continue and use an if (but not nesting too deep as in the Rob's sample code).

回答8:

I don't think continue could ever be as difficult as goto since continue never moves execution out of the code block that it is in.

回答9:

If you are iterating through any kind of a result set, and performing operations on said results, for e.g within a for each, and if one particular result caused a problem, its rather useful in capturing an expected error (via try-catch), logging it, and moving on to the next result via continue. Continue is especially useful, imo, for unattended services that do jobs at odd hours, and one exception shouldn't affect the other x number of records.

回答10:

1. Using continue at the beginning of a loop to avoid iteration over unnecessary elements is not harmful and can be very useful, but using it in the middle of nested ifs and elses can turn the loop code into a complex maze, to understand and validate.

2. I think its usage avoidance is also the result of a semantic misunderstanding. People who does never see/write 'continue' keyword on their code, when seeing a code with continue can interpret it as "the continuation of the natural flow". If instead of continue we had next, for instance, I think more people would appreciate this valuable cursor feature.

回答11:

goto can be used as a continue, but not the reverse.

You can "goto" anywhere, thus break flow control arbitrarily.

Thus continue, not nearly as harmful.

回答12:

Others have hinted at it... but continue and break are enforced by the compiler and have their own associated rules. Goto has no such limitations, though the net effect might almost be the same, in some circumstances.

I do not consider continue or break to be harmful per se, though I'm sure either can be used poorly in a way that would make any sane programmer gag.

回答13:

I'd say yes. To me, it just breaks the 'flow' of a fluidly-written piece of code.

Another argument could also be that if you stick to the basic keywords supported by most modern languages, then your program flow (if not the logic or code) could be ported to any other language. Having an unsupported keyword (ie, continue or goto) would break that.

It's really more of a personal preference, but I've never had to use it and don't really consider it an option when I'm writing new code. (same as goto.)

回答14:

As far as this programmer is concerned, Nested if/else considered harmful.

回答15:

Continue is a really useful function in most languages, because it allows blocks of code to be skipped for certain conditions.

One alternative would be to uses boolean variables in if statements, but these would need to be reset after every use.

回答16:

continue feels wrong to me. break gets you out of there, but continue seems just to be spaghetti.

On the other hand, you can emulate continue with break (at least in Java).

for (String str : strs) contLp: {
    ...
       continue contLp;
    ...
}

continue can be useful in some circumstances, but it still feels dirty to me.

for (char c : cs) {
    final int i;
    if ('0' <= c && c <= '9') {
        i = c - '0';
    } else if ('a' <= c && c <= 'z') {
        i = c - 'a' + 10;
    } else {
        continue;
    }
    ... use i ...
}

回答17:

I believe the bottom line argument against continue is that it makes it harder to PROVE that the code is correct. This is prove in the mathematical sense. But it probably doesn't matter to you because no one has the resources to 'prove' a computer program that is significantly complex.

Enter the static-analysis tools. You may make things harder on them...

And the goto, that sounds like a nightmare for the same reasons but at any random place in code.