2

This is how I usually code:

public void foo (int x) {
    if (x == 1) {
        System.out.println("You entered one!");
    } else if (x == 2) {
        System.out.println("You entered two!");
    } else if (x == 3){
        ................. and so on.

I realized that the following also produces the same results:

public void foo (int x) {
    if (x == 1) {
        System.out.println("You entered one!");
        return;
    }
    if (x == 2) {
        System.out.println("You entered two!");
        return;
    }
    if (x == 3) {
        ...... and so on.

Which one would be better to use, even though they produce the same results and why? I realize that there is a switch statement.

TACO
  • 145
  • 1
  • 1
  • 6
  • 5
    I would personally go for a `switch` – awksp May 27 '14 at 01:21
  • 1
    Or a lookup table. Seriously, there is no 'best'. What is best is what is best for you. Note that the compiler will transform the second form into the first form anyway, so the usual reason advanced "functions shoudl only have one entry and one exit" doesn't stand up to close examination. – user207421 May 27 '14 at 01:23
  • How about without a switch statement? – TACO May 27 '14 at 01:23
  • 1
    Readability suffers when you use multiple `returns` - IMHO. When you have a series of complex, compound `if` statements, missing a single `return` can quickly ruin any understanding you had of the code - and yes, this happens to me all the time and I hate it. I'm old school, I was taught that there should be only one entry and exit point to a function/method. Sometimes that makes the code a little difficult to write, but in doing so, it makes it (generally) easier to read. There are exceptions to every rule, however ;) – MadProgrammer May 27 '14 at 01:23
  • Deeply nested functions can be improved by early returns. But you shouldn't have deeply nested functions anyway... hmmm... – Derek May 27 '14 at 01:25
  • Too many returns are not good for a person trying to read and understand your code. Computers are intelligent enough to process too many returns in a code but humans are not. – Juned Ahsan May 27 '14 at 01:26
  • possible duplicate of [Is there any appreciable difference between if and if-else?](http://stackoverflow.com/questions/2677843/is-there-any-appreciable-difference-between-if-and-if-else) – Boj May 27 '14 at 01:28
  • Well, I prefer doing the internationalisation stuff - having messages like these off in a properties file, so I can easily localise if required. I might use the integer `x` as part of the key, in which case I wouldn't need any `switch/case` or `if/else` or `if/return` logic. But this is completely opinion based and should probably be closed. – Dawood ibn Kareem May 27 '14 at 01:32
  • I see less reason for the "only one return rule" in languages, such as Java, that include try-finally or equivalent, because adding code to every return path does not require editing every return path. – Patricia Shanahan May 27 '14 at 07:47

2 Answers2

0

In this case, there will be almost no performance diffence. It comes down to readability.

I personally prefer a switch:

switch(x) {
    case 1:
        System.out.println("You entered one!");
        break;
    case 2:
        System.out.println("You entered two!");
        break;
    case 3:
        System.out.println("You entered three!");
        break;
}
Anubian Noob
  • 13,426
  • 6
  • 53
  • 75
-2

This is a "primarily opinion-based" question, but the main opinions are:

  1. if/else (or, more importantly, fall-through to return) is better because it's bad to exit in the middle of a method. It's bad to exit in the middle because code should be structured with nested blocks ({}) and a logical progression of setup and the mirror takedown logic, and a return in the middle can result in bypassing takedown logic, often introducing subtle bugs.
  2. if/return is better because exiting in the middle of a method is "cleaner". If the method is designed to fall-through to the return, one tends to get more and more deeply nested conditionals, as logic later in the method bypasses the "error" or "quick exit" cases that would have been handled by an embedded return. This can result in subtle bugs, and makes the code messy.

Obviously, both can't be right. Or can they?? In some cases the first argument would hold sway, in other cases the second. Anyone who claims that there's a hard-and-fast rule one way or the other (that isn't simply restating a language restriction) is just parroting some "expert" who has never really done real programming.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151