-2

Today I received code review comments from a senior developer, one thing he pointed out is that each function should have only one return statement. I wonder whether this is just code style issue or there is security issue, i.e. potential function stack problem or uninitialized variables. Can anyone provide an example(I prefer C\C++\C#) to show the cons of multiple return statement? Thanks a lot.

Jackie
  • 2,476
  • 17
  • 20
  • 1
    This question is probably better suited to codereview.stackexchange.com – Mike Gardner Mar 22 '13 at 03:54
  • IIRC (a quick google search didn't turn up anything, and I don't remember where I read it), this came about because old C or Fortran compilers or something would get all horked up if you had multiple returns. Nowadays, though, this isn't a problem. I'd say it's absurd to be opposed to multiple returns, but then again, some people have multi-page methods, and in that situation, I can see why it would upset you (though the real problem is your methods' insanity). – Joshua Cheek Mar 22 '13 at 03:57
  • It is probably true for any language that doesn't have garbage collection. – Tchoupi Mar 22 '13 at 03:58
  • My coding style is to *return on all independent paths* and *not* to use a "return value variable" which is often required in a style with a single return statement. This effectively means many of my functions have *more* than one return statement. I use C# and JavaScript predominantly: this might not work so well in a language - *cough* C *cough* - that requires manual cleanup across paths. –  Mar 22 '13 at 03:59

2 Answers2

1

in assembly, all functions have to restore the stack after setting it up in the beginning of the function. This means there is no escape from the function, unless you are willing to write the clean up stack code multiple times, which is not too good for space efficiency.

this only applies to functions that actually have parameters or call other functions or store local variables, a flat system assembly can return anytime it wants.

It is much easier to reason about program correctness with one entry, and one return, as few loops and jumps as possible, and with an intent. Multiple return statements throws a lot of people off(people still manage to adapt though).

I wouldn't call multiple returns evil, sometimes they are necessary, and in many times, make sense, such as a factorial program.

Dmytro
  • 5,068
  • 4
  • 39
  • 50
1

A Google search will turn up hours of reading on this topic. The short version is that many older languages would only allow one return point. Also, in older procedural coding styles it was common to have methods that were thousands of lines long. Even if it was not a language requirement, many people found it easier to read the code if there was a single return at the bottom of each method.

Fast forward to today. If you are following object-oriented best practices, mainly the Single Responsibility Principle, your methods should be < 50 lines long and easy to read. Having multiple return points is not a problem. In fact, they help prevent deeply-nested code.

I'll end it there; I just noticed this StackOverflow question. Give that a read.

Community
  • 1
  • 1
mr_plum
  • 2,448
  • 1
  • 18
  • 31
  • FWIW: The accepted answer on that page is actually an *uhg-pattern* in my book .. –  Mar 22 '13 at 04:04
  • I don't know what a *uhg-pattern* is, but I use guard clauses all the time. – mr_plum Mar 22 '13 at 04:11
  • 1
    Returning early. I branch every if-else in such a case (with very few exceptions) and return in both divergent paths. I like multiple return points. I don't like return points that aren't on "leaf nodes". Maybe it's just "preferences influenced by functional languages" .. but still an *ugh-pattern* to me. –  Mar 22 '13 at 04:24