Difference between "return" at the end of the method and "return" placed before the end of the method in java?

Difference between "return" at the end of the method and "return" placed before the end of the method in java?.

If we place the "return" statement before the end of the method like the following code, what will happen?

boolean sample()
{
  boolean b=false;
  int a=0;

  if(a==0)
    return(true);            //This return what happens
  ret开发者_Python百科urn(false);
}

Whether it will increase the burdon of the system than the normal "return" at the end of the method?

No, it makes no difference at all.

Some people like to structure their methods to only have a single return statement, always at the end - personally I tend to return as soon as the code knows the result. I find that ends up with more readable code, particularly if you can tell the result immediately in some cases (e.g. "if the input is null, the output is null") but there's significant processing in others.

Difference between "return" at the end of the method and "return" placed before the end of the method in java?

There is no semantic difference.

The only think to watch is that an unconditional return statement can result in statements following it being unreachable; e.g.

    int a = 0;
    return a == 0;
    int b = 1;       // compilation error here ... statement is unreachable
    return b == 1;

Whether it will increase the burdon of the system than the normal "return" at the end of the method.

No it won't. The generated bytecode (and native code) can have multiple return instructions if necessary.

However, for clarity / readability it is better to write these two statements:

    if (a == 0) return (true);
    return (false);

as a single statement:

    return a == 0;

and there's no need to use parentheses in Java return statements.

All returns are alike. In your example, you don't need more than one return.

return a == 0;

I would suggest you not worry about performance issues, until you can see/measure that you have a problem. Most of the performance issues people worry about in forums won't make any real difference.

Multiple returns are simply multiple exist points from your method, they do not put any "extra burden" on the system and they are no different than "normal" returns.

The method will exit on when it reaches the first return and no other code will be executed after it executes the return statement. Control will then return to the calling method

What Jon Skeet said is correct, if the function got the correct result then let it return the result immediately, rather than waiting the function to do unnecessary checking, looping, etc. This makes the function get faster result + better readability

There's nothing inherently wrong with having multiple return's within a method, it can be elegant to do so. Most recursive functions will have muliple returns:

public String flattenTree(Node currentNode, String stringSoFar) {
    // do our work on this node
    stringSoFar = stringSoFar + currentNode.getName();

    // end condition- if we've got no children left we're done so leave now
    if (currentNode.countChildren() ==0) {
       return stringSoFar;
    }

    // recursive condition- keep digging through the children of our current node
    for (int i=0; i<currentNode.countChildren(); i++) {
         stringSoFar = stringSoFar + flattenTree(currentNode.getChild(i));
    }
    return stringSoFar;
}

Looks nice and clean, and lets you clearly mark out your end condition... I quite like this approach simply because it's built to look like you were taught to do recursion back at school...

Nothing wrong with compacting that into a single return:

    public String flattenTree(Node currentNode, String stringSoFar) {
    // do our work on this node
    stringSoFar = stringSoFar + currentNode.getName();

    // loop through children if neccessary
    for (int i=0; i<currentNode.countChildren(); i++) {
         stringSoFar = stringSoFar + flattenTree(currentNode.getChild(i));
    }

    return stringSoFar;
}

Less code, arguably better, arguably less obvious where your end-case lies...

In terms of performance I couldn't claim to know that one is more/less performant than the other, but I have to say that unless I'm working on an uber-performance-critical piece of code I always pick readability over performance, and I would suggest that at least in this hypothetical example you pick multiple returns for ease of reading.