0

In my organisation, we follow MISRA coding guidelines. This coding guideline says that we should not have the multiple returns in a function.Do you have any idea on it? Why is it so?

dexterous
  • 5,684
  • 9
  • 42
  • 84
  • 2
    I, and many others, consider this a terrible way to write code 100% of the time. I think its reasoning had more strength back when it was introduced, but has since lessened. – chris Dec 16 '13 at 05:26
  • Long functions with multiple return paths are hard to read. Keeping your functions as short as possible also helps with readability. – Matthew Lundberg Dec 16 '13 at 05:27
  • 2
    I personally don't like this rule. Prevents things like guard clauses. – Mark Garcia Dec 16 '13 at 05:27
  • 1
    Are you asking us what we think of this rule, or are you asking us to read the minds of the people who put together the standard? I think it's an awful rule, but those who swear by it insist it makes code easier to reason about. I can provide a counter example for every example they offer. – Joe Z Dec 16 '13 at 05:28
  • 1
    @chris it has lessened with RAII. Prior to that idiom, multiple return paths were dangerous. – Matthew Lundberg Dec 16 '13 at 05:28
  • 5
    What about the very common idiom `if (trivial_case) return trivial_answer;` followed by the rest of the function? I suggest putting the rest of the function in an `else` clause does not aid readability. – Joe Z Dec 16 '13 at 05:30
  • @MatthewLundberg, Yeah, that's where `goto cleanup;` would come in handy. – chris Dec 16 '13 at 05:31
  • @JoeZ, One of my main reasons against it is indentation. Try writing code to deal with `HRESULT` return values that uses this, doesn't use `goto`, and doesn't look like a giant arrow. – chris Dec 16 '13 at 05:32
  • 1
    @chris: What does MISRA say about `goto`? In the past, the same folks who once tried to push "single-exit" on me also said "no `goto`", "maximum cyclomatic complexity of 10" and other crazy things. – Joe Z Dec 16 '13 at 05:32
  • 1
    MISRA is not meant to be universally applicable guidance. – Ben Voigt Dec 16 '13 at 05:33
  • @JoeZ, Seems to me like saying "Go ... yourself". RAII beats out the `goto` and `goto` beats out whatever's left after both of those are in there. – chris Dec 16 '13 at 05:34
  • In any case, we're probably going to repeat everything said here eventually: http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement – chris Dec 16 '13 at 05:35
  • 1
    @chris: I'm glad I don't have to deal with MISRA myself. I just looked it up, and it also bans `goto`. I have a hard time believing that nerf-coating the language like this is an acceptable substitute for competence. Hey, at least they allow `break` (but they don't allow `continue`). – Joe Z Dec 16 '13 at 05:36
  • @JoeZ, I sometimes use `continue` the same way as `return`: `if (!trivial condition) {continue;}`. Granted this happens a lot less commonly. – chris Dec 16 '13 at 05:40
  • 3
    It is quite a bad idea to tag such a question C and C++ at the same time. C++ has destructors, C hasn't so the needs and methods for doing cleanup on function exit are not at all comparable. – Jens Gustedt Dec 16 '13 at 06:21
  • So your organization doesn't allow recursive functions as well? – zar Dec 16 '13 at 07:20

3 Answers3

1

A function with multiple return statements is confusing and is not easy to understand if the method is too big. You may accidentally skip few lines that should be executed.

If you are writing a small program that doesn't need any future maintenance it may be okay to ignore that rule. However for longer programs that may be maintained in future, when people do bug fix after some time, it is quite possible to overlook some block of code returning back to the calling function and put some code below that block assuming that it will run. One such example may be clean up code.

It can be easily argued that programmer should be more careful, but following one return policy will make it easier to avoid such mistakes.

Buddha
  • 4,096
  • 2
  • 22
  • 49
  • And the nature of those lines that should be executed? If it's destructors, it matters less with RAII. – Matthew Lundberg Dec 16 '13 at 05:29
  • 4
    Is "multiple return statements' the problem or "long, confusing function" the problem? Are you treating the symptom or the disease? – Joe Z Dec 16 '13 at 05:29
  • The inherent confusingness of functions with multiple returns is at least highly debatable. Guard clauses are one example of using them to make things clearer. – cHao Dec 16 '13 at 05:35
  • @JoeZ ha ha.. good comment. However, both actually, one worsens the other. Sometimes when people do bug fix after some time, it is quite possible to overlook some block of code returning and put some code below that block. But as you have said, it is also easy to bring up examples where it is a good idea to have multiple statements. No approach is fool proof. – Buddha Dec 16 '13 at 05:36
  • If there's something that you need to do in every case, then that's a slightly different situation -- and if you're the one adding that something, then you should consider refactoring to avoid the repetition. But if you follow the one-return rule religiously, you inevitably end up adding nesting and extra flags and moving parts that then have to be taken into account. You're basically manufacturing more cognitive load for the reader. I'd argue that all that extraness shouldn't be there til it *has* to be. – cHao Dec 17 '13 at 21:50
1

First a single return is somewhat easy to maintain and understand. Second having multiple returns could most likely mean we are returning a value directly rather than quantity. It makes a function much easier to understand. Let me give you a simple example.

Multiple return example

CalculateInterest(int cost)
{
    if (cost < 100)
       return cost * .2;
    else
       return cost * .3;
}

Same function with single return

CalculateInterest(int cost) 
{
    float interest;

    if (cost < 100)
        interest = cost * .2;
    else
        interest = cost * .3;

    return interest;
}
Daniel Serodio
  • 3,711
  • 5
  • 36
  • 32
zar
  • 9,241
  • 10
  • 74
  • 145
1

I disagree that functions should never have more than one return. There are times when an early return can make the code easier to read and maintain.

function DoStuff
{
  if ( simpleCondition ) return result;

  DoComplcicatedProcess
  return complicatedOperatotionResult;
}

Yes it's possible to wrap this a conditional but in this case it's easy to read and potentially more efficient.

Ben Hobbs
  • 84
  • 3