Exit methods with return

[Mihai Radulescu]

I use return statement more than once (when this is necessary) like in the code :

boolean method (String in) {
boolean ret = false;
if(in == null) {
return ret;///here 1
}

...
do stuff
...

ret = true;
return ret; //here
}

Is this a good ?

[Mark Spritzler]

Well personally I think a method should hav oly one return. That is completely my opinion.

In your example you can change your code as such

 
public boolean myMethod(String s) {
  boolean returnValue = false;
  
  if (s != null) {
 
    //Do Stuff
    returnValue = true;
  }
  
  return returnValue;
}
 

Mark

[Baps Vakkalagadda]

A method can have more than one return statement but no two statements must be in the same block.

The below snippet is incorrect because both the return statements come under the same block of code. In this case, JVM complains saying "unreachable ...". But the code that Mihai wrote is valid.

boolean method(String str)
{
  boolean ret=false;
  // do stuff 1
   return ret;
  // do stuff 2
  ret=true;
  return ret;
}

[Mark Spritzler]

"But the code that Mihai wrote is valid."

Actually, his question isn't about the validity of doing what he is doing. It is about what is the best way to handle it.

Mark

[Jon Entwistle]

That is completely my opinion.

Any many others . It is generaly considered that have anything but a single return statement at the very end of the method is, while perfectly correct, bad style as it makes the code more difficult to read and easier to misinterpret.

[Mihai Radulescu]

I agree with you Jon, if the code has more exit points is more difficut to read and interpret, BUT , this is not always.

Most of the time I try to avoid this kind of "multiple return" but when the solution seams to get to complex,I just make it easy with an extra retun.

My question is still : Is this a valid technique (for the developer exam and general) ?

[Jon Entwistle]

I would say that you really shouldn't - if you feel the need, reconsider your algorithm. Remember the three golden guidelines from the cover of 'The practice of programming' by Kernigan and Pike - 'Simplicity, Clarity, Generality' (the first two apply here)

Cheers,

Jon
[ May 27, 2004: Message edited by: Jon Entwistle ]

[Mark Spritzler]

"when the solution seams to get to complex"

This is when I relook at my code and see how I can further break it apart into more methods, if the method is complex then it is probably doing more than one thing. If you try to keep it simple and take the approach of "A method should do one thing and one thing only, then you will find that you will have very little if never chances of needing more than one return.

It is clues like these that help in seeing where to refactor. Clues like needing more than one return.

Good Luck.

Mark

[Mihai Radulescu]

Yes Mark, you are right, the best way is to break the "mammoth" methods in to small "mammoth" methods with (clear)specific task. I know about, I read about(all the develop. exam book mention this) but ....
TahnX.

[Mark Spritzler]

"but ...."

There are no butts er buts.

Have only one return, 98% of the time. and you are guaranteed not to lose points. If you have more than one return, you also might not lose points (85% chance*), but you also might lose points (15% chance*).

Mark

* chance percentages are based on a poll by Associated Press and CNN, there is a 15-85% margin of error.