Is use of only one return statement is considered as a good programming practise?

[Himanshu Gupta]

If we have multiple returns statement in a single method then what is the fuss about it? Don't it saves the processing if in case we return early based on some business rule. Someone said me that there should be only one return statement in a function.

[Ravikanth kolli]

It is not a requirement but is considered as a best practice.
Having only one return statement for a method will make it more readable, while having many will only make the flow haphazard and difficult to understand.

[Bear Bibeault]

I hail from the FORTRAN days of structured programming and so I will tend towards the single return construct by training and nature. But only if it makes sense. If I have to contort the code to achieve a single return, I'll use multiple returns.

I prefer clarity to dogma.

[fred rosenberger]

I mostly agree with Bear. Follow your companies coding standards first. Then, write the code that is the easiest to follow/read/understand.

Everything else being equal, I prefer a single exit point.

[Ernest Friedman-Hill]

Ravikanth kolli wrote:
Having only one return statement for a method will make it more readable, while having many will only make the flow haphazard and difficult to understand.

Sometimes, sometimes not. If the alternative to multiple returns is keeping a flag variable whose only purpose is to keep track of whether to return early or not, then I generally prefer the multiple returns. With the flag, you have even more stuff to understand.

Of course, an even better alternative is to keep your methods short enough, with a coherent-enough purpose, that they don't need to have multiple returns in the first place.

[Jayesh A Lalwani]

I would consider differrent choices and pick the one that leads to smaller code. That's my rule of thumb. Less code to write. Less code to maintain.

If the choice is between

    
void foo()
{
       if(some condition)
       {
           do A
           do some cleanup
           return
       }
       do B
       do some cleanup
       return
}

OR

    
void foo()
{
       if(some condition)
       {
           do A
           
       }
       else
       {
           do B
        }
       do some cleanup
       return
}

I would use second version. THere's less stuff to maintain there

OTH if my choice is between

    
void foo()
{
       A a= null;
       try
      {
           a = create something
           a.doSOmething()
       }
       catch(SOme Exception e)
       {
           do some exception handling 
           return;
       }
      a.cleanup();
      return;
}

OR

    
void foo()
{
       A a= null;
       try
      {
           a = create something
           a.doSOmething()
       }
       catch(SOme Exception e)
       {
           do some exception handling 
       }
      if(a!=null)
      {
            a.cleanup();
      }
      return;
}

I would do

    
void foo()
{
       A a= create something;
       try
      {
           a.doSOmething()
           a.cleanup();
       }
       catch(SOme Exception e)
       {
           do some exception handling 
       }
      return;
}

Yes I cheated Certainly, these are very simplified examples, and it doesn't always work out so simply. Lines of code is just a rule of thumb. IMO, in most cases, you can make it simple enough with some creativity

[Bear Bibeault]

I would again point out that clarity should rule. Less lines of code aren't always clearer -- in fact, sometimes just the opposite -- so I would caution against using line count as a metric.