1

I got something from a former Google employee's blog. He said Google employees used to have conventions for Java if condition like this:

if (condition) {
    return x;
} else {
    return y;
}

But later inside Google it was changed to be like this:

if (condition) {
    return x;
}
return y;

It seems that there are similar or duplicate questions on SO (e.g. this one), and I also checked the Oracle official Java Code Conventions for this. I'm just curious about the difference between them even if it is negligible.

I'm not looking for opinions or what people prefer, but rather whether there is any actual, discernible difference here or if it truly is just a matter of style.

TylerH
  • 20,799
  • 66
  • 75
  • 101
Sam Su
  • 6,532
  • 8
  • 39
  • 80
  • Personally, I'm old school and work with in principle of "one entry point and one exit point". To me, that would mean using a single `return` statement. This makes it less likely that you are going to miss a `return` statement when reading the code, especially if there are more then two in a long method. I don't know about optimization, but I would say that is more about readability then optimization... – MadProgrammer Aug 05 '13 at 05:11
  • if the first condition is fulfilled you return x. With else block or without else block it will return y so it's more clear without else block. – Bertrand Martel Aug 05 '13 at 05:12
  • 1
    IMO the answer is: http://programmers.stackexchange.com/a/118748/47845 – assylias Aug 05 '13 at 05:37
  • tks for the link, and I don't know this kind of question should be posted at SO or http://programmers.stackexchange.com/ – Sam Su Aug 05 '13 at 05:51
  • @Sam Probably more on programmers: "Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development." – assylias Aug 05 '13 at 05:59

5 Answers5

2

I would personally like to choose

if (condition) {
    return x;
} else {
    return y;
}

This is much more readable for me, with or without the braces. These are return statements, so it might not make much difference. But lets say they are just statements, like the example below:

if (condition){
    //some statements
} else {
    //some related statements
}

This code as time progresses might lead to something like below

if (condition){
    //some statements
} else {
    //some related statements
}
//some totally unrelated statements

In such a case you clearly distinguish which ones are the ones that are affected by the condition. In the future, when you need to refactor it out, it might be easier.

As you might see, its just a personal taste. I would recommend you to check with your lead/architect/peers and see if they have a preference. As a thumb rule, it would be better to go with the team's preference than your own.

Indu Devanath
  • 2,068
  • 1
  • 16
  • 17
0

This is one of the better code formatting recommendations.

If you are using Eclipse, you can enable this warning in the Preferences. It will let you know such code blocks where unnecessary else conditions are there.

RaceBase
  • 18,428
  • 47
  • 141
  • 202
0

Functionally, there is no difference. Personally, I would prefer the second one, simply because I don't like adding extra stuff if it doesn't do anything in the program.

Technically, in the second snippet, you don't even need the curly braces, however I recommend that they are there to improve readability of the code, and to maintain quick-scan comprehension.

I don't know quite how the code would translate into JBC, but I wouldn't be surprised if the else actually made more instructions be executed than without the else.

If you were to do more than a simple return, I would suggest using the else with braces, but otherwise, simply follow the structure of snippet #2.

Pandacoder
  • 708
  • 7
  • 11
0

There is no difference (functional and performance) as condition in both cases gets evaluated. Difference lies in code structure and formatting practices different people/organization applies.

Some argue having else is more verbose or explicit.

PMD and Findbugs have rules (warning level) of code quality that else is redundant. So if you have default template enabled of these code-analysis tools, warning report would contain such pieces/method calls.

On have multiple return statements, it is advisable (again similar settings in PMD and FindBugs) to avoid since it decreases code readability. For simpler code like you posted it looks ok to have two return but consider having complex conditional logic where on different condition return different values, understanding code wouldn't be easy. Its better (ideal) to have lesser return statement some argue having just one:

int data = DEFAULT;
if(condition) {
  data = XYZ;
} else if(condition) {
  data = DDD;
}
return data;
harsh
  • 7,502
  • 3
  • 31
  • 32
  • The case for having only one return statement [is a bit outdated](http://programmers.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from). – assylias Aug 05 '13 at 05:36
  • @assylias appreciate you sharing the link, really interesting insight! – harsh Aug 05 '13 at 07:23
0

There is no difference in code's logic and I believe it could be even compiled into exactly the same bytecode in both cases. It's more about personal preferences. Here is a short list of factors involved in favor of the former approach:

  1. There's no "third option" as in the first example. Although Java compiler is smart enough to detect that, there is no way for a function not to finish its execution (return) within if or else block, the first code looks like there could be such a case. Especially when your code grows up, and return statemenets are no longer so clearly visible.
  2. Limit the number of opened curly brackets - that's more important in my opinion. You should always try to limit number of nested blocks ({...}) to the minimum - code is almost always much more readable that way:

    for (...) {
        if (...) {
            if (...) {
                // this sucks, 3 levels of indention
            }
        }
    }
    
    for () {
        if (!...) {
            continue;
        }
    
        if (!...) {
            continue;
        }
    
        // maybe there's more code but it's much easier to read and maintain
    }
    
Crozin
  • 43,890
  • 13
  • 88
  • 135