[C++] Never have more than 1 return statement?

[Jamin2112]

I know someone at Google who says you should never have more than 1 return statement in a function. That seems ridiculous to me.

Let's take a simple example. Suppose we need a function that finds the maximum value of any C++ array.

I can do

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    if (n == 0)
    {
        return false;
    }
    else
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
        return true;
    }
}

or, equivalently,

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    bool retval;
    if (n == 0)
    {
        retval = true;
    }
    else
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
        retval = false;
    }
   return retval;
}

Apparently, the first is considered bad because it has two return statements? The second seems very n00b-esque to me. (I know there's an even better way to do the whole function.)

 

[ShayanJ]

No, the first one is completely OK. I have no problem with it.

 

[DavidSnider]

This advice was popularized in "Code Complete" which suggested you minimize returning early except when it would enhance readability.

I find the biggest benefit of the "one exit point" that you only need to set one breakpoint when debugging.

Though if you are keeping your functions small and uncomplicated this probably won't be much of an issue anyway.

 

[AlephZero]

Personally, I would be more worried about the value not returned in "highest" than about the number of return points

 

[D H]

This advice was popularized in "Code Complete" which suggested you minimize returning early except when it would enhance readability.

The "single point of entry / single point of exit" rule goes back much further than Code Complete. This rule is very old. The first part of the rule gives a clue as to how old this rule is. The facility to define alternate entry points to a function doesn't exist in C or C++, or in most other languages for that matter.

It's an old rule based on archaic concepts. It deserves to die.

I find the biggest benefit of the "one exit point" that you only need to set one breakpoint when debugging.

This benefit goes away with debuggers such as gdb that let you set a break point on the function's closing bracket.

Another supposed advantage of a single exit point is cleanup. Suppose a function creates and connects to a socket, opens a C-style stream, allocates an array via new, copies data from the socket to the stream, and then cleans things up. There are lots of things that can go wrong here. There's no point in continuing if the socket won't open properly, and then there's no stream to close, no array to delete. There are multiple ways in which the socket connection can fail, and the socket can fail while reading from it. The cleanup can be *ugly*. In fact, some advocate using goto to branch into the right part of the cleanup section.

There is a way around this cleanup problem in C++: Use RAII. Do this consistently and once again the impetus driving a single exit point vanishes.I'm a fan of "early exit". Suppose you've done a good job defining your functions in terms of preconditions, invariants, and postconditions. What to do about those preconditions? Suppose you are reading a complex function and the first thing you see are a handful of statements of the form

// Handle preconditions.

if (! precondition_1) {
   issue_error_message("Precondition 1 failed");
   return;
}

if (! precondition_2) {
   issue_error_message("Precondition 2 failed");
   return;
}

You know exactly what these checks are doing: They're ensuring the preconditions are met. That's the principle of least astonishment at work. The alternative of a single exit point can be more astonishing. You have to scroll all the way down to see that these preconditions just exit. Even worse, you may have to diagram some rather convoluted logic introduced just to comply with the "single point of entry / single point of exit" rule.

Though if you are keeping your functions small and uncomplicated this probably won't be much of an issue anyway.

Yep. The arguments I've seen for single point of entry / single point of exit are usually straw men. For example,

// 100s of lines of code elided
if (some_test) {
   return ERROR_CODE_1;
}
// 100s of lines of code elided
for (i = 0; i < first_limit; i++) {
   // 100s of lines of code elided
   if (some_other_test) {
      return ERROR_CODE_2;
   }
   // 100s of lines of code elided
   for (j = 0; j < second_limit; j++) {
      // 100s of lines of code elided
      if (yet_another_test) {
         return ERROR_CODE_3;
      }
      // 100s of lines of code elided
   }
   // 100s of lines of code elided
}
// 100s of lines of code elided
return SUCCESS;

That this code has four exit points interspersed randomly throughout several hundred lines of code is only the tip of the iceberg of the problems associated with this block of code.

 

[craigi]

The rationale behind it, is that if someone who is unfamiliar with the code wants to do something at the end of the function for all cases, then they can miss a return point and introduce a bug.

People who analyse this sort of stuff can estimate how often mistakes like this happen and their cost to a project. Future languages may even make it impossible.

I do it some cases, but then I'm mindful of how someone might modify my code and what I want the compiler to do with it.

 

[AlephZero]

The rationale behind it, is that if someone who is unfamiliar with the code wants to do something at the end of the function for all cases, then they can miss a return point and introduce a bug.

How did they know they wanted to do something at the end for all cases, unless they traced all the possible ways they could get to the one return point?

Thinking or assuming they wanted to do something in all cases (e.g. by believing or misunderstanding the documentation, but not actually reading the code) might also be a bug!

 

[D H]

The rationale behind it, is that if someone who is unfamiliar with the code wants to do something at the end of the function for all cases, then they can miss a return point and introduce a bug.

I've heard lots of excuses for the "single point of entry / single point of return", but I haven't heard this one before. That's pretty lame.

People who analyse this sort of stuff can estimate how often mistakes like this happen and their cost to a project.

Name one. Citation needed.

Future languages may even make it impossible.

This thread isn't about speculative directions in computer language development. It's about C++.

That said, those future languages will most likely formalize the concepts of preconditions and postconditions. That isn't the case in C++, which is why you will oftentimes find code that implements those preconditions in the form of early exit or throwing an exception.

In addition to those early exits, another common use for multiple returns in C++ is a search function. These two paradigms, using return statements for preconditions and a successful search, are widely used and widely accepted amongst professional C++ programmer.

Can return statements be abused, make code more confusing? Of course. Just because they can do so when used inappropriately does not mean they almost always do. More importantly, there are places where a return statement can enhance readability / understandability.

 

[craigi]

How did they know they wanted to do something at the end for all cases, unless they traced all the possible ways they could get to the one return point?

Thinking or assuming they wanted to do something in all cases (e.g. by believing or misunderstanding the documentation, but not actually reading the code) might also be a bug!

When you're working with other people's code, you don't always fully understand the functions that you're modifying nor do you always need to. It's not ideal, but many experienced software developers have experienced, it at some point.

I've heard lots of excuses for the "single point of entry / single point of return", but I haven't heard this one before. That's pretty lame.

It's certainly not lame if you're working on very large scale, safety critical projects.

Name one. Citation needed.

Jean Ichbiah et al took this very seriously, for example.

More importantly, there are places where a return statement can enhance readability / understandability.

Agreed. Very small functions and functions that are clearly structured for early-outs, are good examples. If you care about performance, they can also be used to coax the compiler into generating more optimal code, in certain cases.

I can do

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    if (n == 0)
    {
        return false;
    }
    else
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
        return true;
    }
}

or, equivalently,

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    bool retval;
    if (n == 0)
    {
        retval = true;
    }
    else
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
        retval = false;
    }
   return retval;
}

Regarding the OP, both of those functions are completely horrible. More structure to your programming will certainly help and in this case, a single exit should actually make your code simpler. Perhaps then you'll actually see the bugs in it. I can see 2 reasons why the first function doesn't even work straight away, one very dubious omission and one extra bug introduced by refactoring it for the second function.

 

[jim mcnamara]

McCabe's static code metric algorithm actually counts function returns as part of determining 'cyclomatic complexity' - a measure of the feasibility of code testing, primarily a result of code branching. It is old.

McCabe T. J., "A Complexity Measure". IEEE Transactions on Software Engineering 1976

My point is not about McCabe's approach, good or bad, but the fact that the algorithm counts "extra" return statements as negative dings the to the overall result. More returns are supposed to be bad. I believe this kind of thing has fostered the idea: 'more than one return in a function is bad'

Also see: http://en.wikipedia.org/wiki/Cyclomatic_complexity

 

[jim mcnamara]

@craigi - on PF, and in Science in general, a citation means just that: author,( journal or book) title, article title or chapter citation, date.

The most common reference for Jean Ichbiah is understandably: Ada

 

[craigi]

@craigi - on PF, and in Science in general, a citation means just that: author,( journal or book) title, article title or chapter citation, date.

The most common reference for Jean Ichbiah is understandably: Ada

Sure, but I'm already happy with my contribution to the thread. Thank you for your contribution too. Searching for citations to support what we both already know seems fruitless and I'm content for anyone who doubts it to disregard it, out of hand.

 

[D H]

It's certainly not lame if you're working on very large scale, safety critical projects.

That is what exactly what I do: Projects in the MSLOCs that can result in billions of dollars of damages, loss of life, and loss of national prestige.

But don't take my word for it. Let's look at a coding standard for a large scale, safety critical project that has been widely promulgated throughout the large scale, safety critical C++ community, the Joint Strike Fighter C++ Coding Standard (http://www.stroustrup.com/JSF-AV-rules.pdf) (emphasis theirs):

4.13.2 Return Types and Values
AV Rule 113 (MISRA Rule 82, Revised)

Functions will have a single exit point.

Rationale: Numerous exit points tend to produce functions that are both difficult to understand and analyze.
Exception: A single exit is not required if such a structure would obscure or otherwise significantly complicate (such as the introduction of additional variables) a function’s control logic. Note that the usual resource clean-up must be managed at all exit points.​

Note that this is a will rather than a shall requirement, and also note that the rule has an explicit exception.

Jean Ichbiah et al took this very seriously, for example.

That is not a citation.

McCabe's static code metric algorithm actually counts function returns as part of determining 'cyclomatic complexity' - a measure of the feasibility of code testing, primarily a result of code branching. It is old.

McCabe T. J., "A Complexity Measure". IEEE Transactions on Software Engineering 1976

My point is not about McCabe's approach, good or bad, but the fact that the algorithm counts "extra" return statements as negative dings the to the overall result. More returns are supposed to be bad. I believe this kind of thing has fostered the idea: 'more than one return in a function is bad'

Also see: http://en.wikipedia.org/wiki/Cyclomatic_complexity

Whether return statements raise the cylcomatic complexity is subject to debate. A return statement is equivalent to goto __close_brace. It's just another edge in the local graph. On the other hand throwing an exception, calling exit, or calling some project-specific function that acts like an exception (i.e., the function doesn't return to the caller) is an alternate exit point, and they do bump the complexity.

 

[jedishrfu]

For references, the Apple/IBM Taligent project published a Taligent's Guide to Designing Programs, Well Mannered Object Oriented Design in C++

While Taligent is defunct, the guide is still useful for coding standards.

On page 52 Things to Avoid: Don't Use goto

They mention avoiding the use of returning from the middle of a procedure as something that should be reviewed with the project architect. The reasoning is that it could subvert the meaning and correctness of the code requiring you to read all the relevant code to see what's going on.

https://www.amazon.com/dp/0201408880/?tag=pfamazon01-20

 

[AlephZero]

On page 52 Things to Avoid: Don't Use goto

The problem with over-simple "rules" is that they are too easy to subvert, as in the OP's code where "goto end-of-function" is replaced by the state variable "retval" which has no other purpose in the code. One of my work colleagues used to call this style of coding "the if-come-from statement" or "backwards programming" (and less complementary names which probably don't meet the PF posting guidelines!)

Of course there are much more creative ways to subvert a "no gotos" or "only one return" rule than he OP's method, as D.H. already mentioned - throwing user-defined exceptions, etc.

 

[D H]

Things to Avoid: Don't Use goto

I've only seen the use of goto "justified" in a tiny number of cases.

Case 1 (very rare): The code gets in trouble deep inside multiply nested loops. This can happen, for example, with some bizarre corner cases in singular value decomposition. While SVD is typically very robust, there are some weird corner cases that defeat this robustness. The problem is that the problem isn't uncovered until deep in the bowels of the SVD algorithm. There would be no problem with this problem if C/C++ had a multilevel break capability. The goto statement provides a way to emulate this missing capability.

Case 2 (much more common): Some fool of a manager has mandated the single point of entry / single point of exit rule, with no exceptions allowed. Some programmer complains that the only alternatives are to add unneeded complexity to the code or to use gotos. The manager's response: "That's right. This is one of those cases where gotos are the preferred implementation."


I for one much prefer to see preconditions dealt with up-front in a manner that clearly calls them out as such. A small (one to three) statement blocks of the form if (simple_test) { log_error(); return; } at the head of a function won't bug me in the least -- so long as those preconditions are clearly documented. Those up-front statements tell a nice Principle of Least Astonishment story.

On the other hand, I've been asked to participate in a code review of a function with over 200 lines of code and a cyclomatic complexity in excess of 20. Those numbers alone bedeviled me beyond belief. That that tangled mess of code of contained buried return or goto statements will just cemented the deal.

 

[.Scott]

I may be the only one here who really remembers where the "one exit" rule came from.

It was in rebellion to "spaghetti code" - especially prevalent among FORTRAN programmers doing maintenance coding. It came with strict adherence to the basic programming structures ("structure programming").

There is clearly some absurdity to it - as there was with the strict dictates of structure programming. Although it was (and is) true that you could not have spaghetti code with strictly structured programming, what you do get is truly obscure flags to signal which path you want to take.

Personally, I do subscribe to "GOTOless" code - although I wouldn't go so far as to forbid it. My main concern is being able to follow the code - and until you've tackled a system with hundreds of pages, you;re probably not going to catch on to what that means.

Basically, you should realize that there are many ways to implement an algorithm and the one you want to pick is the one that has an easy to follow human-language "story".

As far as single exit coding, like craigi, I commonly deal with safety related or military mission-critical systems and so I give the auditors their due. Some people feel very strongly that there should be only one exit - and I do not care to spend my time fighting them.

So, here is how I would implement the code - allowing for one exit while retaining "sensibility":

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    bool bOkay;

    //
    // Check valid input (or any other description of why your are checking "n")
    bOkay = n != 0;
    if(bOkay)
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
    }
    return bOkay;
}

Sometime the solution is not quite so simple. Very commonly, there will be many, many exit conditions. The most common solution for avoiding numerous "returns" is to start nesting if statements - one or two levels of nesting for each error condition checked. For example, you're opening a file and you want to check the file name, whether it can be opened, whether a malloc works, whether the filesize is adequate, whether the first 10 bytes are "MyFileType", etc. Wouldn't you love to go "if(!malloc(...)) return MYERR_MALLOC;"?

Here's one not-that-bad method - using an enumeration variable "eErrorState":

enum { MYERR_NOERROR=0, MYERR_BADNAME, MYERR_NOFILE, MYERR_MALLOC } MYERR;
MYERR eErrorState;

eErrorState = MYERR_NOERROR;
//
// Check filename
if(!eErrorState) {
  ...
  if( error condition ) {
    eErrorState = MYERR_BADNAME;
  }
}
//
// Check file
if(!eErrorState) {
  ...
  if( error condition ) {
    eErrorState = MYERR_NOFILE;
  }
}
...

Not bad, but I prefer this:

enum { MYERR_NOERROR=0, MYERR_BADNAME, MYERR_NOFILE, MYERR_MALLOC } MYERR;
MYERR eErrorState;

eErrorState = MYERR_NOERROR;
//
// Non-loop to make for easy "break".
for(;;) {
  //
  // Check filename
  ...
  if( error condition ) {
    eErrorState = MYERR_BADNAME;
    break;
  }
  //
  // Check file
  ...
  if( error condition ) {
    eErrorState = MYERR_NOFILE;
    break;
  }
  ...
}
return eErrorState;

 

[craigi]

So, here is how I would implement the code - allowing for one exit while retaining "sensibility":

template <class T>
bool max (T* arrPtr, size_t n, T highest)
{
    bool bOkay;

    //
    // Check valid input (or any other description of why your are checking "n")
    bOkay = n != 0;
    if(bOkay)
    {
        for (T* i(arrPtr), j(arrPtr + n); i != j; ++i)
            if (*i > highest)
                highest = *i;
    }
    return bOkay;
}

This is a beautiful illustration of 2 things that I was talking about earlier in the thread.

Firstly, it's the simplification that I was referring to that the single exit point paradigm offers in this case.

Secondly, it's easy to see from it how programmers make modifications to functions that they don't fully understand. This shouldn't be taken as a critisism of .Scott, rather just as an observation of how a programmer typically modifies unfamilar functions. In this case he has rightly presumed that he could do no harm to this function by modifying it to have a single exit point, but has also inadvertently copied the 3 serious issues, from the OP's original function, that I was referring to earlier.

Now this is an incredibly simple function. In the case of a more complex function, it really isn't a huge leap of the imagination to see how a programmer attempting make a modification to a function without understanding it in its entirety actually introduces new errors in the false belief that they have done no harm. A more structured programming style defends against these scenarios.

I actually take a very liberal approach to coding standards, but they can serve as a very useful learning resource for inexperienced programmers. Enforcing coding standards is no fun for anyone, but if I were confronted with someone checking in any of the iterations of this function in this thread to a codebase that I was using, I would just delete and rewrite it.

 

[D H]

craigi, while you may see .Scott's solutions as "beautiful", those who advocate early return as the preferred mechanism for dealing with invalid inputs (failed preconditions) will inevitably use a rather different adjective to describe that code. I see what .Scott's wrote as exemplifying why one *should* use early return rather than shun it.This is a programming religion issue. As far as I can tell, there are no studies that compares "single point of entry / single point of return" versus early return with regard to readability, understandability, maintainability, etc. There's only religion. From my experience, mandating religious issues rarely works. Those religious mandates cause managers to tell the programmers who work for them to ignore the programming standards. All of them. I've seen this happen, multiple times.

The "single point of entry / single point of return" rule ranks right up there with regard to causing dissension as do the "no magic numbers" rule (which taken to its extreme results in nonsense such as #define ZERO 0) and the yoda convention rule (which results in inscrutable code such as if (ZERO != number) ...).

 

[Jamin2112]

Regarding the OP, both of those functions are completely horrible. More structure to your programming will certainly help and in this case, a single exit should actually make your code simpler. Perhaps then you'll actually see the bugs in it. I can see 2 reasons why the first function doesn't even work straight away, one very dubious omission and one extra bug introduced by refactoring it for the second function.

I feel like an idiot sometimes. I understand that I didn't pass highest as a reference and didn't initialize it inside the function.

How about this:

template <typename T> T max(T* arr, size_t n)
{
    if (n == 0)  /* I know most people programmers prefer "if (!n)" */
        throw("The max of an empty array is undefined, bro.");

    /* The rest doesn't need to be in an "else" statement, even though the intent of
        the function is to execute the rest of the code only if the "if" condition isn't met */
    T highest = arr[0];
    for (T* i(arr+1), j(arr+n); i != j; ++i) 
    /* Pointer arithmetic starting at the memory address after the first element of the array and
        continuing until one-off-the-end of the array */  
        if (*it > highest)
              highest = *it;
        return highest;
}

I'm sure a C++ purist will have some fancier routine that involves forward iterators, recursion, etc.

 

[.Scott]

craigi, while you may see .Scott's solutions as "beautiful", those who advocate early return as the preferred mechanism for dealing with invalid inputs (failed preconditions) will inevitably use a rather different adjective to describe that code. I see what .Scott's wrote as exemplifying why one *should* use early return rather than shun it.

This is a programming religion issue. As far as I can tell, there are no studies that compares "single point of entry / single point of return" versus early return with regard to readability, understandability, maintainability, etc. There's only religion. From my experience, mandating religious issues rarely works. Those religious mandates cause managers to tell the programmers who work for them to ignore the programming standards. All of them. I've seen this happen, multiple times.

The "single point of entry / single point of return" rule ranks right up there with regard to causing dissension as do the "no magic numbers" rule (which taken to its extreme results in nonsense such as #define ZERO 0) and the yoda convention rule (which results in inscrutable code such as if (ZERO != number) ...).

I agree. My motivation for creating such code is to placate high priests.

The real problem is that there is such a thing as "bad code" - as demonstrated by the widespread success of computer viruses that exploit bad code. This real problem motivates some managers to establish "coding standards" to prohibit "bad code". Unfortunately, you can't turn bad cooks into good cooks by forcing them to hold their cooking utensils in special aesthetically graceful ways. It may make the cooking look better - but you'll still get indigestion.

 

[craigi]

I feel like an idiot sometimes. I understand that I didn't pass highest as a reference and didn't initialize it inside the function.

How about this:

template <typename T> T max(T* arr, size_t n)
{
    if (n == 0)  /* I know most people programmers prefer "if (!n)" */
        throw("The max of an empty array is undefined, bro.");

    /* The rest doesn't need to be in an "else" statement, even though the intent of
        the function is to execute the rest of the code only if the "if" condition isn't met */
    T highest = arr[0];
    for (T* i(arr+1), j(arr+n); i != j; ++i) 
    /* Pointer arithmetic starting at the memory address after the first element of the array and
        continuing until one-off-the-end of the array */  
        if (*it > highest)
              highest = *it;
        return highest;
}

I'm sure a C++ purist will have some fancier routine that involves forward iterators, recursion, etc.

1 old bug which I'd still argue wouldn't have existed if your code had a more structured style.

1 new bug, but to be fair it looks like a typo.

They're both compile errors so running it through a complier will throw them up.

Don't worry about forward iterators or recursion, but if you want to improve on it, pay particular attention to the use of copy constructors. If T is a built-in type then it makes no difference, but for class types things get more complicated. You've actually hit on a little quirk of C++ called "named return value optimisation", which means that your function can actually have different behaviour on different compilers! You can write this entire function without involving a single copy constructor, which might serve as a useful exercise.

Also, think about your motivation for using c++ exceptions. If the only reason is to dodge the single exit point debate, then it's a heavy price to pay. The bottom line is that you should be mindful of where you put your exit points. You can argue it either way and for such a small function it makes very little difference.

 

[jbunniii]

You're also using the assignment operator for T a lot more than necessary:

    T highest = arr[0];
    for (T* i(arr+1), j(arr+n); i != j; ++i) 
    /* Pointer arithmetic starting at the memory address after the first element of the array and
        continuing until one-off-the-end of the array */  
        if (*it > highest)
              highest = *it;
        return highest;

Why not just keep track of the index of the maximum, and then at the end, return the array element at that index? Something like

size_t idxOfMax = 0;
for (size_t i = 1; i < n; i++)
    if (arr[i] > arr[idxOfMax])
        idxOfMax = i;
return arr[idxOfMax];

 

[harborsparrow]

Every rule has an exception. The example given is trivial and thus, it does not harm to return from 2 different places. However, for long subroutines or functions, returning from multiple places can lead to difficult-to-read code. The real point made by Code Complete, the book famous for promulgating this rule, is to make your code easily understandable to any outsider who looks at it, or might have to maintain it in the future. As long as you keep this principle firmly in mind, you'll be OK.

One advantage to returning from a single point can be if you are logging progress--the code which logs progress need only be in one place. After many years of coding experience, I began logging progress in all my code. This enabled me to troubleshoot when I got unexpected reports of errors from users--I could see what they had been doing when the error occurred. So I logged, not just errors, but basic calls (and results returned). This had to be done efficiently but was a capability well worth developing. I always log as I enter and leave a function. The slight overhead of this has been well worth it, and if the overhead cannot be afforded, then you can make the logging itself have an on/off capability. But I found it held me to the discipline of having a single point of return.

Some people will fight this, but I am very, very experienced at writing user interface code that goes to a lot of users. They always, always, encounter something what wasn't caught in testing, and mechanism such as single point of return, with error logging, can save your bacon when that happens. My current group of a dozen or so users have grown so accustomed to this that they now automatically send me their log files along with any trouble report. Saves a mountain of time for everyone. 99% of the time, the log file directs me quickly to the problem.

 

[jbunniii]

I always log as I enter and leave a function. The slight overhead of this has been well worth it, and if the overhead cannot be afforded, then you can make the logging itself have an on/off capability. But I found it held me to the discipline of having a single point of return.

Why not instantiate an object whose constructor and destructor log the entry/exit? Then it's irrelevant whether you have a single point of return or not. I've done something similar when measuring the amount of time spent in various functions.

 

[D H]

This rule is much older than Code Complete (a book that should be on every profession programmer's essential reading list). Steve McConnell was reiterating what *some* held as common wisdom. Here's what McConnell wrote in Code Complete:

Minimize the number of returns in each routine. It's harder to understand a routine if, reading it at the bottom, you're unaware of the possibility that it returned somewhere above.

Use a return when it enhances readability. In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any cleanup, not returning immediately means that you have to write more code.​

Even McConnell left an out. (The authors of the JSF coding standards similarly left an out.) If return statements enhance readability and understandability, use them. If all they do is obfuscate, don't use them. A return statement buried deep in some convoluted logic has zero redeeming value.

Personally, I **hate** this rule on the basis that it causes more harm than good. The underlying intent is certainly good, but good intentions are what the road to the underworld is paved with.

 

[harborsparrow]

Why not instantiate an object whose constructor and destructor log the entry/exit? Then it's irrelevant whether you have a single point of return or not. I've done something similar when measuring the amount of time spent in various functions.

This is a way to log. It might be less obvious to someone reading the code. And finding the deconstructor is not always easy.

There are also code injection technologies, if tracing code execution is all one is after.

I'm after a lot more than simply tracing execution. I may also log returned values upon exit. I'm always thinking about what I'd need to see in the log if a trouble report comes.

Personally, I like to stick to the "single point of return" rule most of the time, because I've found it helps me read the code again late--especially if I have to come back to it after a lot of time has lapsed.

 

[Borek]

Personally, I like to stick to the "single point of return" rule most of the time, because I've found it helps me read the code again late--especially if I have to come back to it after a lot of time has lapsed.

(bolding mine)

I think most of us agree with the general sentiment. As DH wrote, problems start when the rule becomes a religion.

IMHO that's the problem with most of the similar rules used in programming. They work great most of the time, but there are moments when religiously sticking to them just produces code that becomes unreadable, or unnecessarily complicated.

 

[gmar]

I know someone at Google who says you should never have more than 1 return statement in a function. That seems ridiculous to me.

In some languages that is OK.

 

[Mark44]

In some languages that is OK.

That's not in dispute. What this thread was about was whether it was good practice to have exactly one return statement in a function. As D H has said, this "rule" has become something of a religious controversy, akin to the controversy about where the opening brace for a for loop, while, loop, if block, etc. should go: on the same line or on a new line.

 

[gmar]

That's not in dispute. What this thread was about was whether it was good practice to have exactly one return statement in a function. As D H has said, this "rule" has become something of a religious controversy, akin to the controversy about where the opening brace for a for loop, while, loop, if block, etc. should go: on the same line or on a new line.

There is certainly some dispute over the former issue.

As for the latter, your editor or IDE can automatically reformat code when you open it.

I am much more interested in the GOTO issue that was mentioned earlier in the thread. It's actually standard practice in quite a lot of places.

I do not think it's religion. It can simply be a case of insufficient self-introspection. A programmer assumes that his own field of programming as practiced by his cohorts represents the sum total of all programming and doesn't realize other subgroups are working in very different environments with different idioms.

 

[TylerH]

I agree with most of the posts in this thread. IMO, it's completely pointless to force a single return when many would simplify the code. But I have a professor that enforces the single return rule on all of his assignments. I've mentioned to him that I think the rule is absurd (it's a small department and I know him well) and he responded by telling me that it messes up a lot of invariants necessary for a lot of optimizations. He did research in compilers at a upper-middle level school during his PhD, so he has the background to know this with certainty. I've never pressed him for what exactly it is that the multiple returns messes up, as it would likely be an involved discussion I wouldn't completely understand anyway (thus doing so would show inconsideration for the value of his time). I know this doesn't really mean much because I can't substantiate anything, but it might be worth considering. Does anyone here have any idea what he could mean?

PS Even knowing this, I still use multiple returns, mainly because I have a policy against coding for optimizations. I code algorithms. If compilers can't generate efficient code for an efficient algorithm, IMHO, that's the compiler writers' problem and not worth my effort unless it's causing me performance problems in a hot segment of code.

 

[craigi]

I agree with most of the posts in this thread. IMO, it's completely pointless to force a single return when many would simplify the code. But I have a professor that enforces the single return rule on all of his assignments. I've mentioned to him that I think the rule is absurd (it's a small department and I know him well) and he responded by telling me that it messes up a lot of invariants necessary for a lot of optimizations. He did research in compilers at a upper-middle level school during his PhD, so he has the background to know this with certainty. I've never pressed him for what exactly it is that the multiple returns messes up, as it would likely be an involved discussion I wouldn't completely understand anyway (thus doing so would show inconsideration for the value of his time). I know this doesn't really mean much because I can't substantiate anything, but it might be worth considering. Does anyone here have any idea what he could mean?

I seriously doubt that he's correct, that compilers don't handle multiple exit points well, but I think I can outline his argument, though it's difficult to explain stuff that is wrong.

Inside the body of a function that isn't to be inlined, the compiler assigns registers to variables. There's a finite number of registers available. If a register already contains a value that is needed after the function call, its contents needs to be stored on the stack, typically at the start of a function and the value needs to be loaded back into the register from the stack before exitting from the function. The stack is typically stored in the fastest memory available, but memory access is often significantly slower than register access.

There's extra complexity, in that different processors give different penalties for failed branch predicition, and in some circumstances, it's better to execute extra instructions and disgard their result in order to remove branches and dodge a branching penalty.

The reason I think it's not relevant, is that it's trivial for a compiler to unite exit points, in the same way that a programmer would. In fact, early exits allow compilers to use less registers, in those instances. Typically, when writing performance critical code, I would tend towards multiple exit points, rather than away from them.

Complier behaviour does vary and early releases of compliers have unexpected behaviours. Typically, compiler optimisation involves analysing the most common use-cases and mutiple exit points is a relatively common pattern. Nevertheless, if you're writing performance critical code, you tend to disassamble it anyway and modify the C++ to coax the compiler into producing the correct code. If it's stubborn, then moving to assembly is the only solution.

PS Even knowing this, I still use multiple returns, mainly because I have a policy against coding for optimizations. I code algorithms. If compilers can't generate efficient code for an efficient algorithm, IMHO, that's the compiler writers' problem and not worth my effort unless it's causing me performance problems in a hot segment of code.

Whether or not you should optimise for performance, really depends upon the circumtances and there are cases where it's very important that a section of code completes within a fixed time on fixed hardware. Hoping that a new version of a complier is going to turn up before you need to meet that demand isn't a sensible solution. Alternatively, if it doesn't really matter to you how long it takes your code to complete, then you should prioritise other things such as maintainability and minimisation of bugs.

A good programmer, develops a style that practises all these considerations in a particular balance and constantly re-examines their style based upon how they currently percieve the desirable characterisitics of their code.

 

[D H]

There is certainly some dispute over the former issue.

As for the latter, your editor or IDE can automatically reformat code when you open it.

That's problematic when you have to check your code into a revision control system and the project dicta that mandate that all checked-in code must be formatted per a strict set of rules. I've yet to meet an automated reformatting tool that properly converts all the nuances of style A to all the nuances style B.

To me, the easiest way around this problem is to relax those project-wide dicta. This becomes especially important for big projects, those with many tens of thousands lines of code or more. Should there be consistency within a file, or some logical grouping of files? Absolutely. Should there be consistency across a project that comprises a million lines of code? No. Now the project manager is imposing his or her own computing religion.

I am much more interested in the GOTO issue that was mentioned earlier in the thread. It's actually standard practice in quite a lot of places.

The only places where I've seen GOTO used are

• In ancient code that dates from the 1970s or earlier.
• In not so ancient code where the programmers saw 1970s era code as a "how to" example of best practices.
• In some finite state automata, where the natural transition from one state to another is to go to that other state.
• In organizations that have mandated the single point of entry / single point of return as an anti-pattern.

I have successfully shot down incorporating the single point of entry / single point of return rule into a project's coding standards by innocently asking "so does that mean we can use goto?"

To me, the easiest way around this problem (goto and return) is that code needs to be subject to peer review. It's impossible to specify in rules all of the ways that code can be "wrong". Someone used a O(n³) algorithm where an O(n log(n)) algorithm will do? That code is wrong, but try writing a programming standard that says not to do that. Humans remain the best bug detectors. That's why we review code. Stinky code ("code smell") is another area where standards just don't quite work. We all know stinky code when we get too close to the screen and smell it. Multiple return statements can be a sign of code smell. "Your code stinks" from a peer reviewer is always a relevant comment that needs to be addressed.

I agree with most of the posts in this thread. IMO, it's completely pointless to force a single return when many would simplify the code. But I have a professor that enforces the single return rule on all of his assignments. I've mentioned to him that I think the rule is absurd (it's a small department and I know him well) and he responded by telling me that it messes up a lot of invariants necessary for a lot of optimizations. He did research in compilers at a upper-middle level school during his PhD, so he has the background to know this with certainty.

That is true to some extent. A return deep inside a multiply-nested loop is almost inevitably going to raise havoc with an optimizer. The same is true for goto and break statements. Those statements mess with the loop invariants, thereby precluding a lot of optimizations. On the other hand, an early return such as a check that the user input mass of an object is positive doesn't mess with those loop invariants. Advanced languages have a concept of preconditions and postconditions. Older languages such as C and C++ do not, and as a result you get design patterns such as early return.

A well-established design pattern in an older language is a built-in feature or perhaps even a no-op or in a more advanced language.

 

[gmar]

That's problematic when you have to check your code into a revision control system and the project dicta that mandate that all checked-in code must be formatted per a strict set of rules. I've yet to meet an automated reformatting tool that properly converts all the nuances of style A to all the nuances style B.

That's weird since doing a custom extension for an existing extensible code formatter is probably a weekend's work for an intern.

My programming background is embedded systems in C. We do a lot of things the majority of non-realtime coders don't like, but in all honesty, the majority of idiomatic code arguments are all based on soft factors so comparing it to a religion is a pretty good analogy. At least until, for example, we get some really good formal verification tool which chokes on multiple exit points in a function.

Now would probably not be a good time for me to mention the exception vs return code "debate".

I didn't like the tone of my reply, so I edited it.