循环中的条件，最佳实践？

Question

Say I have a loop like this:

for (int i = 0; i < someint; i++)
{
    if (i == somecondition)
    {
        DoSomething();
        continue;
    }
    doSomeOtherStuff();
}

Versus...

for (int i = 0; i < someint; i++)
{
    if (i == somecondition)
    {
        DoSomething();
    }
    else
    {
        doSomeOtherStuff();
    }
}

Is there any reason to use one over the other? Or is it just personal preference?
The main language I'm asking this for is Java, but I guess it also applies to most others.

Answer 1

从技术上讲，不，但我发现第二个更适合这个特殊情况。

Answer 2

I prefer the second construct...

for (int i = 0; i < someint; i++)
{
    if (i == somecondition)
    {
        DoSomething();
        //lets say lot of code
        //..
        //...
        //...
        //...
        continue;
    }
    else
    {
        doSomeOtherStuff();
    }
}

Lets say you had lot of code before the continue . It is immediately apparent just by looking

   else
    {
        doSomeOtherStuff();
    }

the it is not executed unconditionally .

Answer 3

To me, this depends on what's the split between the then and the else branch relative sizes: if one is massively larger than the other, and the smaller one represents a logically exceptional situation, I put the shorter one into then , and add a continue ; when they are roughly equal, both in size and in the logic flow, I keep them in their own then and else branches.

for (String tok : tokens) {
    if (isKeyword(tok)) {
         output.write(tok);
         continue;
    }
    // Do some massive processing of non-keyword tokens here
    // This block goes on...
    // and on...
    // and on... You get the idea
}

vs.

for (String op : operators) {
    if (isAdditive(op)) {
        // Do something for additive ops
    } else {
        // Do something for non-additive ops
    }
}

Answer 4

I would definitely prefer the second syntax.

Try to avoid continue statements wherever possible. It makes the code path more difficult to follow and therefor difficult to debug

Answer 5

As everyone said, the second form is recommended. Many coding standards recommend you to avoid "continue" and "break" statements because it adds complexity to your code.

Just to give you a reference:

JSF++ (Rule 190) and Misra C (Rule 57) say:

The continue statement shall not be used.

Those are standards for safety-critical applications, but they can be applied to other apps as well.

Misra is paid, but JSF++ can be downloaded for free here:

http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc

It is for C++, but many rules can be applied to other languages. It worths the reading!

Answer 6

In this particular case, I agree with everyone else that the second is preferable. But there are cases where I'd go for the first. If DoSomething() were really just that one call, and i == someCondition is an edge case, and doSomeOtherStuff() were actually 20 lines of code instead of just that one call, then I'd prefer using the continue . In that scenario, I read it as "first, let's take care of this one edge case quickly. Okay, now let's do the real stuff."

Of course, one could make the argument for the if-else by rephrasing my interpretation to "if we're in the edge case do this, else do the real stuff." But that means all those 20 lines are now one nesting deeper, and to me it's more readable to take care of the edge cases first, and then focus on the common path.

Answer 7

I actually do believe there is a pertinent reason to prefer the first over the second, although in most cases, the second is definetely more readable .

Say for example you have a lot, and I mean a lot of conditions inside your loop, where by having a lot of if statements actually affects readability through indentation:

for ( int i = 0 ; i < n ; i++ )
{
   if ( obj[i] )
   {
      doSomething();
      if ( someOtherCondition() 
      {
           //...........
                                                  if ( /* some levels down */ )
                                                  {

                                                  }
           //.....
      }  
   }
}

I might get arguments like "You can refactor it" blah blah, but sometimes , rarely, you simply can't.

So you can refactor and make it a lot more readable with:

for ( int i = 0 ; i < n ; i++ )
{
   if ( !obj[i] )
   {
       continue;
   }
   doSomething();
   if ( !someOtherCondition() 
   {
       continue;
   }
   //...........  
}

Answer 8

I think it depends more on what you are doing.

This is a simple example, but as a rule if there is a condition that I'm "Extracting" from other loop logic, I will pull it out as quickly as possible with a continue rather than adding to the complexity of future if statements (your first example IF it is a condition that can be extracted simplifying future logic) For instance:

for ( int i = 0 ; i < n ; i++ )
{
    if( obj[i] != null && obj[i].instanceOf("A")) {
        doSomething();
    } else if(obj[i] != null && obj[i].instanceOf("B"){
        doSomethingElse();
    }
}

NOW it's clear that extracting the first condition into

if(obj[i] == null) {
    continue;
}

could save some confusion as this loop gets enhanced. I use this tactic a lot for testing method parameters and either returning early or throwing an exception.

Also (This is totally an aside, not part of the answer at all!), I'd say that if you ever see a "Truly" balanced condition you might give a serious thought to your OO design. If doSomething and someOtherCondition were that similar, they should probably be different implementations of a method defined in a base class or interface, leading to this code:

for ( int i = 0 ; i < n ; i++ )
{
    obj[i].doSomething();
}