Another way to use continue keyword in C++

Question

Recently we found a "good way" to comment out lines of code by using continue:

for(int i=0; i<MAX_NUM; i++){
  ....
  .... //--> about 30 lines of code
  continue;
  ....//--> there is about 30 lines of code after continue
  ....
}

I scratch my head by asking why the previous developer put the continue keyword inside the intensive loop. Most probably is he/she feel it's easier to put a "continue" keyword instead of removing all the unwanted code...

It trigger me another question, by looking at below scenario:

Scenario A:

for(int i=0; i<MAX_NUM; i++){
  ....
  if(bFlag)
    continue;
  ....//--> there is about 100 lines of code after continue
  ....
}

Scenario B:

for(int i=0; i<MAX_NUM; i++){
  ....
  if(!bFlag){
  ....//--> there is about 100 lines of code after continue
  ....
  }
}

Which do you think is the best? Why? How about break keyword?

Answer 1

Using continue in this case reduces nesting greatly and often makes code more readable.

For example:

for(...) {
    if( condition1 ) {
        Object* pointer = getObject();
        if( pointer != 0 ) {
            ObjectProperty* property = pointer->GetProperty();
            if( property != 0 ) {
        ///blahblahblah...
        }
     }
}

becomes just

for(...) {
    if( !condition1 ) {
        continue;
    }
    Object* pointer = getObject();
    if( pointer == 0 ) {
        continue;
    }
    ObjectProperty* property = pointer->GetProperty();
    if( property == 0 ) {
       continue;
    }

    ///blahblahblah...
}

You see - code becomes linear instead of nested.

You might also find answers to this closely related question helpful.

Answer 2

Think on readability first, which is what is going to make your code more maintainable. Using a continue statement is clear to the user: under this condition there is nothing else I can/want to do with this element, forget about it and try the next one. On the other hand, the if is only telling that the next block of code does not apply to those for which the condition is not met, but if the block is big enough, you might not know whether there is actually any further code that will apply to this particular element.

I tend to prefer the continue over the if for this particular reason. It more explicitly states the intent.

Answer 3

That "comment" use of continue is about as abusive as a goto :-). It's so easy to put an #if 0/#endif or /*...*/, and many editors will then colour-code the commented code so it's immediately obvious that it's not in use. (I sometimes like e.g. #ifdef USE_OLD_VERSION_WITH_LINEAR_SEARCH so I know what's left there, given it's immediately obvious to me that I'd never have such a stupid macro name if I actually expected someone to define it during the compile... guess I'd have to explain that to the team if I shared the code in that state though.) Other answers point out source control systems allow you to simply remove the commented code, and while that's my practice before commit - there's often a "working" stage where you want it around for maximally convenient cross-reference, copy-paste etc..

For scenarios: practically, it doesn't matter which one you use unless your project has a consistent approach that you need to fit in with, so I suggest using whichever seems more readable/expressive in the circumstances. In longer code blocks, a single continue may be less visible and hence less intuitive, while a group of them - or many scattered throughout the loop - are harder to miss. Overly nested code can get ugly too. So choose either if unsure then change it if the alternative starts to look appealing.

They communicate subtly different information to the reader too: continue means "hey, rule out all these circumstances and then look at the code below", whereas the if block means you have to "push" a context but still have them all in your mind as you try to understand the rest of the loop internals (here, only to find the if immediately followed by the loop termination, so all that mental effort was wasted. Countering this, continue statements tend to trigger a mental check to ensure all necessary steps have been completed before the next loop iteration - that it's all just as valid as whatever follows might be, and if someone say adds an extra increment or debug statement at the bottom of the loop then they have to know there are continue statements they may also want to handle.

You may even decide which to use based on how trivial the test is, much as some programmers will use early return statements for exceptional error conditions but will use a "result" variable and structured programming for anticipated flows. It can all get messy - programming has to be at least as complex as the problems - your job is to make it minimally messier / more-complex than that.

To be productive, it's important to remember "Don't sweat the small stuff", but in IT it can be a right pain learning what's small :-).

Aside: you may find it useful to do some background reading on the pros/cons of structured programming, which involves single entry/exit points, gotos etc..

Answer 4

For your first question, it may be a way of skipping the code without commenting it out or deleting it. I wouldn't recommend doing this. If you don't want your code to be executed, don't precede it with a continue/break/return, as this will raise confusion when you/others are reviewing the code and may be seen as a bug.

As for your second question, they are basically identical (depends on assembly output) performance wise, and greatly depends on design. It depends on the way you want the readers of the code to "translate" it into english, as most do when reading back code.

So, the first example may read "Do blah, blah, blah. If (expression), continue on to the next iteration." While the second may read "Do blah, blah, blah. If (expression), do blah, blah, blah"

So, using continue of an if statement may undermine the importance of the code that follows it.

In my opinion, I would prefer the continue if I could, because it would reduce nesting.

Answer 5

I agree with other answerers that the first use of continue is BAD. Unused code should be removed (should you still need it later, you can always find it from your SCM - you do use an SCM, right? :-)

For the second, some answers have emphasized readability, but I miss one important thing: IMO the first move should be to extract that 100 lines of code into one or more separate methods. After that, the loop becomes much shorter and simpler, and the flow of execution becomes obvious. If I can extract the code into a single method, I personally prefer an if:

for(int i=0; i<MAX_NUM; i++){
  ....
  if(!bFlag){
    doIntricateCalculation(...);
  }
}

But a continue would be almost equally fine to me. In fact, if there are multiple continues / returns / breaks within that 100 lines of code, it is impossible to extract it into a single method, so then the refactoring might end up with a series of continues and method calls:

for(int i=0; i<MAX_NUM; i++){
  ....
  if(bFlag){
    continue;
  }
  SomeClass* someObject = doIntricateCalculation(...);
  if(!someObject){
    continue;
  }
  SomeOtherClass* otherObject = doAnotherIntricateCalculation(someObject);
  if(!otherObject){
    continue;
  }
  // blah blah
}

Answer 6

I hate comment out unused code. What I did is that,

I remove them completely and then check-in into version control.

Who still need to comment out unused code after the invention of source code control?

Answer 7

Continue is useful in a high complexity for loop. It's a bad practice in using in commenting out the remaining code even for temporarily debugging. Since people tends to forget...