Single vs multiple function exit point

Actually i don't exactly have time/drive to delve deeply in this matter right now. Just logging it before it escapes my mind, forgotten for long.

In Martin Fowler's Refactoring: Improving the Design of Existing Code he features many refactoring techniques that encourage cutting methods/functions short and quickly exiting/returning. Yes, he advocates the practice of inserting multiple exit points to improve the readability of the code.

I realise coming from a structured C background in the poly days, i'm one of those with a tendency to place alota conditional checks to branch to different behaviour and placing the final result in a variable for return at the last line. Now i'm indeed cuting out the immense confusion introduced by so many if/else levels and placing multiple returns.

What is your own practice and habit on this particular aspect of programming? Or that of your team's?

Multiple exit points : yes i do use a lot of exit points, but then in most of the cases (in complicated functions) while using a lot of exit points, there tend to be a lot of if else statements.
IMHO it makes code kinda difficult to follow thru..(in case of that lengthy code).
whereas, using a single exit point might be easier to follow thru in a lengthy code.
That's what i think...

For me, I prefer to maintain a single exit point for my function. Personally, I find it easier to trace and understand the program or module better if the exit function is kept at a single point. IMHO, it greatly aids in debugging.

I personally practise and advocate single exit point and try to keep my team in the sample coding practises.

Sometimes when using multiple exit points, it can become messy.  Because you might insert some code, but forget about the cases that have jumped out of the function already.

But other cases are a definite use of return for me though... such as validation steps before processing, or in simple functions - where the only processing is that of calculating the return value, and especially recursive routines.

Boolean functions often make more sense to me in this form, e.g. would you do this differently?

protected override bool SecurityCheck()
{
   if (base.SecurityCheck ())
      return true;

   // Test to see whether a valid active task is busy
   if (!TaskList.IsActiveTaskId(ETASK.TASK_CC_ADD))
   {
      TransferParent();
      return true;
   }

   return false;
}

I love code samples, theory sux

Sorry to be an ignorant person here, but, what is a multiple function exit point?

hannes wrote:

protected override bool SecurityCheck() {    if (base.SecurityCheck ())       return true;    // Test to see whether a valid active task is busy    if (!TaskList.IsActiveTaskId(ETASK.TASK_CC_ADD))    {       TransferParent();       return true;    }    return false; } I love code samples, theory sux

Here's what I would do:

protected override bool SecurityCheck()
{
   bool bReturn = false;
   if (base.SecurityCheck ())
      bReturn = true;

   // Test to see whether a valid active task is busy
   if (!TaskList.IsActiveTaskId(ETASK.TASK_CC_ADD))
   {
      TransferParent();
      bReturn = true;
   }

   return bReturn;
}

If I had to trace this application, all I need is to watch on the variable bReturn to break when it's value changes. Easy way for me

triplez wrote:

Sorry to be an ignorant person here, but, what is a multiple function exit point?

Single Exit Point:

bool TestTest ()
{
   bool bReturn = false;

   // ... stuff here ...
   if (...)
      bReturn = true;
   else 
      bReturn = false;
   
   return bReturn;
}

Multiple Exit Point:

bool TestTest ()
{
   bool bReturn = false;

   // ... stuff here ...
   if (...)
      return true;
   else 
      return false;
   
   return false;
}

Ah. I would do the first way, because it's easier to debug that way, as microlau stated. But the 2nd way allows you to return without performing any other conditional checks. Performance-wise 2nd way gives you a slight advantage, but, with today's technology, I don't think it's really an issue.

You would need an extra else block in the example that I showed though.

Also, the advantage of multiple exit points is no complicated nested if/else blocks. In the sample that you gave, the "else" should be dropped from the multiple exit point one.

With 3 tests:

bool TestTest ()
{
   bool bReturn = false;

   if (...)
      bReturn = true;
   else
      if (...)
        bReturn = true;
      else
        if (...)
          bReturn = true;
        else
          bReturn = false;
  
   return bReturn;
}

Multiple Exit Point:

bool TestTest ()
{
   if (...)
      return true;
   if (...)
      return true;
   if (...)
      return true;

   return false;
}

microlau wrote:

protected override bool SecurityCheck() {    bool bReturn = false;    if (base.SecurityCheck ())       bReturn = true;    // Test to see whether a valid active task is busy    if (!TaskList.IsActiveTaskId(ETASK.TASK_CC_ADD))    {       TransferParent();       bReturn = true;    }    return bReturn; }

And this is precisely where the confusion can set in for me. The above is a short sample. In usual programs these if/else blocks span many more lines and for a single condition, you basically have to trace through all lines in the method and filter in your mind which blocks are ignored until you hit the final return point.

In contemplating Martin Fowler's advice, and in actual experience, if I explictly place the exit point directly where the code no longer needs to continue. I can safely gather the rest of the code is redundant for the condition.

Sure, you could step-trace it, but that means having to run the program and that in itself has some elimination power over the confusion introduced by coding style, because you see it in actual action rather than paper-runs.

I used multiple exit points too. I have a habit of doing:

if (Something == NotRight) return; .. doMoreWork return;

I find that it makes it easier to read my code top down. All the stuff at the top should already been filtered off and those at the bottom will be the ones that fell through.

A single point of exit is the good old fashion practice of structured programming. Its cleaner but can get confusing with too many if-else (s)

Multiple points of exits is more efficient since it avoids unnecessary conditional checks further down the function.

So back to question of speed or maintainability.