Single-entry/single-exit rule [closed]

Answer 1

Also, multiple exits could be some performance issue: when processor runs the current command, at the same clock tick it processes several next commands and performs some operations with them. So, if your code has multiple exits, like this:

if (condition)
  return a;
DoSomething();
if (condition2)
  return b;

and first condition is true, extraction of DoSomething() command will be useless. Actually, with branch prediction it still can be fine, but anyway it is better keep this thing in mind.

Answer 2

No, this is not a rule, and sometimes it is even difficult/impossible to achieve. The code that has one entry and one exit point is easier to understand and debug though. Compare this:

int foo()
{
    if(something)
        return 0;
    //100 lines of code
    if(something)
        return 11;
    //100 lines of code
    if(something)
        return -1;
    //100 lines of code
    return 0;
}

and this:

int foo()
{
    int errorCode = 0;
    if(something)
        errorCode = 1;
    //100 lines of code
    if(something)
        errorCode = 11;
    //100 lines of code
    if(something)
        errorCode = -1;
    //100 lines of code
    return errorCode;
}

Now we have just one exit point, and (taking into account the variable name too) it's much easier to understand what the function does. You can also place a breakpoint onto the last return and know that this is the point where function ends, and that you will definitely hit it.

Answer 3

This rule may apply in C, but it can be considered obsolete in C++ because of exceptions. As soon as your function throws an exception or calls a function that can throw, you have an additional exit point:

int f()
{
  //...
  g(); // g() may throw: you have an exit point here
  //...
  throw exc; // another possible exit point
  //...
  return returnValue; // Nice try, but you have additional exit points
}

This in addition to the point made in other answers: this rule intends to make the code easier to follow, but it is easy to find examples where this is not true. Much better:

if (condition)
  return a;
if (condition2)
  return b;
if (condition3)
  return c;

// Insert all your code for the general case

than:

int returnValue;    
if (!condition) {
  if (!condition2) {
    if (!condition3) {
      // Insert your code here
    }
    else {
      returnValue = c;
    }
    returnValue = b;  // Where am I now?
  }
  returnValue = a;
}
return returnValue;

And then you also have the case when you decide the return value in a switch:

switch (a)
{
  case 1: return 10;
  case 2: return 20;
  case 3: return 40;
  default: return 50;
}

rather than:

int returnValue;
switch (a)
{
  case 1: returnValue = 10; break;
  case 2: returnValue = 20; break;
  case 3: returnValue = 40; break;
  default: returnValue = 50; break;
}
return returnValue; // Where is the clarity gained?

Answer 4

Is this true?

That's what the rule says, in places where it's used and enforced. Is it a good rule? I fight against its adoption tooth and nail. I think its a stupid rule. Worse than stupid: It's a harmful rule for C++.

I do agree with the first part of the rule, "single entry". The Fortran entry statement causes a lot more problems than it solves. This first part of the rule does not pertain to C or C++ for the simple reason that neither language provides a multiple entry point mechanism. "Single entry" is a no-op in C and C++.

So what about "single exit"? Early return does not necessarily cause problems. Failing to deal with allocated resources prior to returning is what causes problems. The right rule is "clean up your mess", or don't leave dangling resources. Single exit does not solve this problem because it doesn't say a thing about cleaning up your mess.

In C, the single entry / single exit rule typically goes hand in hand with allowing (and even encouraging) the use of goto for error handling. I can see the place for goto as used for error handling in the Linux kernel code. But not in C++. This is why I wrote that single entry / single exit is harmful in C++. This rule discourages the use of RAII and exception-safe programming and encourages the use of goto.

Answer 5

I'm personally not opposed to early-exit, but I'll propose a third alternative to SingerOfTheFall for consideration.

Advantages:

• normal code flow (i.e. non-error) flows cleanly through the top of the code
• no chance of failing one "something" and passing another "something" inadvertently executing a block of code
• you can enforce scope on code blocks; including clean-up on exit of scope for things used in sub-blocks of code

Disadvantage:

• indentations can add up (although this can be mitigated by breaking into sub-functions)
• without brace-matching in your editor it can be difficult to match error with failed condition

int foo()
{
    int errorCode = 0;
    if(!something) {
        //100 lines of code
        if(!something) {
            //100 lines of code
            if(!something) {
                //100 lines of code
            }
            else {
                errorCode = -1;
            }
        }
        else {
            errorCode = 11;
       }
    }
    else {
        errorCode = 1;
    }
    return errorCode;
}

Answer 6

You can store your return value in a variable if you want to achieve this, but it's not true. You can have multiple returns in the same function without problems.