Re: goto vs. return?

[al davis]

On Sun, 24 Jan 2016 07:55:49 -0800
Rik <address@hidden> wrote:

> I don't think much of goto, but I do accept intermediate returns as a valid
> style.  What I dislike is the Arrow coding style
> (http://blog.codinghorror.com/flattening-arrow-code/) of which there is a
> lot.  Early returns, a.k.a guard statements, are one way of reducing
> massive indentation.  One versus multiple returns seems to be something
> that programmer's like to debate. 

I think the real answer is to understand what you are trying to
accomplish, then express it as clearly as you can.

It looks a lot worse with that curly-brace style.
Once-upon-a-time, Gnucap did use that style, but I changed it to put
the curlys on the "if" line.

Also, the way "else if" is written there adds several lines.

Also ..  I like to make the empty else explicit, and always use curlys.

Changing these things alone makes it look a lot better:

int arrow()
{
  if (rowCount > rowIdx) {
    if (drc[rowIdx].Table.Columns.Contains("avalId")) {
      do {
        if (Attributes[attrVal.AttributeClassId] == null) {
          // do stuff
        }else if(!(Attributes[attrVal.AttributeClassId] is ArrayList)){
          // do stuff
        }else if (!isChecking) {
          // do stuff
        }else{
          // do stuff
        }
        rowIdx++;
      } while (rowIdx < rowCount && GetIdAsInt32(drc[rowIdx]) == Id);
    }else{
      rowIdx++;
    }
  }else{
    // nothing
  }
  return rowIdx;
}

Without truly understanding what the code is supposed to do, I can't
say if this is the best way to express it.

Back to the original topic ..  I think returns splattered all over is
bad, but assigning to a variable all over and one return at the end
doesn't make it any better.  There needs to be logic and discipline
behind the decision, case by case.