tags:

views:

85

answers:

6

I am following some examples in the book, and I noticed two different conventions for having various return conditions. Is there any difference between the two?

//example 1
if(someCondition)
{
   return (someValue);
}
return (someOtherValue);

//example 2
if(someCondition)
{
   return (someValue);
}
else
{
   return (someOtherValue);
}

Personally, I like the second example better, because it's more explicit, and I feel that it's more readable.

+6  A: 

If your language contains a conditional operator I would recommend using that.

return condition ? ifTrue : ifFalse;
ChaosPandion
Or, at work, you might choose not to use operators that will force SOME people to take an extra few seconds (to minutes) to analyze and possibly discuss. I've seen this waste much time, I've never seen a simple if/then create the same kind of time sink. At home, of course, the more fun the better.
Bill K
I like this shorthand, but it's only useful when the code is simple.
Pasha
@Pasha - You can of course move complex logic into its own method. `return condition ? DoSomethingSpecific() : DoSomethingElseSpecific();`
ChaosPandion
+3  A: 

There is no difference other than the look. Both will return the same, regardless of which you choose.

Erik
+2  A: 

Use whatever is the one you enjoy, and looks best with your code, or whatever your team understands most.

There isn't really a convention for this, as far as I am aware.

Bartek
+1  A: 

Personally I think that it always good to have one return statement in a method, otherwise code can be a bit hard to read and hence unmaintainable. so do something like

def returnVal = default;

if (cond) {
 returnVal = whatever
}

return returnVal
hvgotcodes
In theory I would agree, but trying to get your code to have only one return many times makes it more complicated than it needs to be. Keeping line count in functions small helps multiple returns look clean and understandable.
palto
yes, this is more of an 'artistic' preference. I just think that one return statement per method looks good and makes things clean. Implicit in that is the desire to have small methods to begin with, which also helps.Another argument for this is that IDES like Eclipse and Intellij both give warnings over this. It can be confusing as hell trying to figure out from where a method returns. Unless there is just one return at the end...
hvgotcodes
I think that the single return thing definitely was used when most function calls tended to run in the multi-hundred or thousand line range--at that point finding a hidden return in the middle was hell. Now that we code much smaller methods this tends not to help much (if at all), but many people stick with it because people are creatures of habit and once you tell someone that it's the best way or it looks better this way they tend to stick with it, often religiously.
Bill K
+3  A: 

Personally the case where this comes up a lot is when you are eliminating invalid states from your function/method call. For example:

sqrt(x) {
    if(x < 0)
        return 0;

    answer=math;
        return(answer);

If you use elses, you can end up with a lot of really horrific nesting.

This also involves the "Single return" theory--lots of people think a method should only have one return statement. This also leads to mess in some cases.

In your specific example it's 50/50 IMO.

Do what you like, but I highly suggest giving the "Test immediately and return for simple cases" theory a try.

Bill K
+2  A: 

Avoiding else and taking advantage of early return can keep your code from becoming too deeply nested. Which example looks more readable?

function doStuff (thing) {
  if (thing.foo) {
    alert ("thing.foo is alive and well");
    if (thing.foo.bar) {
      alert ("thing.foo.bar is alive and well");
      if (thing.foo.bar.baz) {
        alert ("thing.foo.bar.baz is alive and well");
        // TODO: stuff with thing.foo.bar.baz
      } else {
        alert ("thing.foo.bar.baz doesn't exist!");
      }
    } else {
      alert ("thing.foo.bar doesn't exist!");
    }
  } else {
    alert ("thing.foo doesn't exist!");
  }
}

or

function doStuff (thing) {
  if (!thing.foo) {
    alert ("thing.foo doesn't exist!");
    return;
  }
  alert ("thing.foo is alive and well");
  if (!thing.foo.bar) {
    alert ("thing.foo.bar doesn't exist!");
    return;
  }
  alert ("thing.foo.bar is alive and well");
  if (!thing.foo.bar.baz) {
    alert ("thing.foo.bar.baz doesn't exist!");
    return;
  }
  alert ("thing.foo.bar.baz is alive and well");
  // TODO: stuff with thing.foo.bar.baz       
}

... I think the second is much more readable!

no