Есть ли какое-либо заметное различие между если и если еще?

Подумайте об этом случае, когда два примера не будут похожи:

    public boolean foo(int input) {
        if (input > 10) {
            // doStuff();
            return true;
        }
        System.out.println("do some other intermediary stuff");
        if (input == 0) {
            // doOtherStuff();
            return true;
        }

        return false;
    }

vs.

    public boolean foo(int input) {
        if (input > 10) {
            // doStuff();
            return true;
        } 
        //System.out.println("doing some intermediary stuff... doesn't work");
        else if (input == 0) {
            // doOtherStuff();
            return true;
        } else {
            return false;
        }
        return false;
    }

Первый подход, вероятно, более гибкий , но обе формулы используются в разных обстоятельствах.

Что касается производительности, я думаю, что различия слишком малы, чтобы их принимать во внимание, для любого обычного java-приложения, написанного здравомыслящими программистами :).

В вашем последнем примере не делайте этого:

public boolean foo(int input) {
   boolean toBeReturned = false;
   if(input > 10) {
      doStuff();
      toBeReturned = true;
   } else if(input == 0) {
      doOtherStuff();
      toBeReturned = true;
   }

   return toBeReturned;
}

, а вот это (обратите внимание на использование Java final ):

public boolean foo(int input) {
   final boolean toBeReturned;    // no init here
   if(input > 10) {
      doStuff();
      toBeReturned = true;
   } else if(input == 0) {
      doOtherStuff();
      toBeReturned = true;
   } else {
      toBeReturned = false;
   }
   return toBeReturned;
}

. Поступая таким образом, вы проясняете свое намерение, и это находка для IDE, поддерживающих «программирование намеренно» (нет необходимости «компилировать», чтобы увидеть потенциальные ошибки, даже на частичном AST, хорошая IDE может исследовать неполный источник в в режиме реального времени и дает вам мгновенные предупреждения).

Таким образом вы уверены , что не забудете инициализировать свое возвращаемое значение. Это замечательно, если позже вы решите, что вам все-таки нужно другое условие.

Я делаю это все время и тем более с тех пор, как начал использовать IntelliJ IDEA (версия 4 или около того, давным-давно), и это спасло меня от множества глупых ошибок отвлечения внимания ...

Некоторые люди будут утверждать, что это слишком много кода для такого простого случая, но он полностью упускает из виду суть: суть в том, чтобы прояснить намерение, чтобы код легко читался и мог быть легко расширен позже, не забывая случайно назначить toBeReturned ] и, случайно не забыв вернуться из более позднего предложения, вы можете добавить.

В противном случае, если бы «краткость» было названием игры, я бы написал:

public boolean foo(int a) {
  return a > 10 ? doStuff() : a == 0 ? doOtherStuff() : false; 
}

Где и doStuff , и doOtherStuff вернут истину.

Версии №1 и №2 могут быть быстрее, чем №3, но я полагаю, что разница в производительности минимальна. Я бы предпочел сосредоточиться на удобочитаемости .

Лично я бы никогда не использовал версию №2. Между №1 и №3 я бы выбрал тот, который дает наиболее читаемый код для рассматриваемого случая. Мне не нравится много точек выхода в моих методах, потому что это затрудняет анализ кода.Однако есть случаи, когда поток становится более ясным, когда мы немедленно выходим из некоторых особых случаев и продолжаем работу с основными случаями.

Семантически - нет.С точки зрения производительности это зависит от компилятора, то есть от того, может ли он определить, что оба условия не могут выполняться одновременно. Готов поспорить, что стандартный компилятор Sun может. Использовать ли принцип единого выхода - зависит от вкусов. Я лично ненавижу это.

Между первым и вторым фрагментами нет никакой разницы. Однако третий фрагмент довольно неэффективен. Поскольку вы ждете, чтобы вернуть управление программой вызывающей стороне до последней строки кода в методе, вы тратите вычислительную мощность / память, тогда как первые два фрагмента кода возвращают управление, как только одно из условий определяется как истинное.

В вашем случае второе if будет вызываться только в том случае, если первое if не удалось, поэтому здесь это менее важно, но если ваше первое if что-то сделало и не вернулось, второе if (которое тогда всегда будет ложным) все равно будет проверено, если оно не было в else-if.

Другими словами, есть случаи, когда разница между if-else-if и if-if имеет значение, но это не один из них.

Пример: попробуйте это, а затем попробуйте после удаления else. Вы получаете два разных результата:

int someNumber = 1;
if(someNumber < 5)
{
    someNumber += 5;
    Console.WriteLine("First call.");
}
else if(someNumber >= 5)
{
    Console.WriteLine("Second call.");
}

Используйте любую форму лучше описывает ваше намерение.

Не следуйте принципу единственного выхода, если все так просто - это только усложняет задачу.

• В первом:

  кто-то в конце концов, по какой-то странной причине и когда вы не смотрите, добавит какое-то дополнительное утверждение, которое заставит этот метод потерпеть неудачу при определенных странных условиях, каждый (или, что еще хуже, один человек) потратит 4 часа.наблюдая за исходным кодом и отлаживая приложение, чтобы наконец обнаружить, что посередине что-то есть.

• Второе определенно лучше, оно не только предотвращает этот сценарий, но и помогает четко заявить, что это это или это другое больше нет.

  Если весь код, который мы пишем в if, где не более 10 строк, это не имело бы большого значения, но, к сожалению, это не так, существуют другие программисты, которые почему-то думают, что тело if должно быть > длиной 200 строк... в любом случае.

• Мне не нравится третья, она заставляет меня искать переменную return, и легче найти ключевое слово return

О скоростных характеристиках они (почти) идентичны. Не беспокойтесь об этом.