Я думаю, что эти фрагменты кода эквивалентны по той простой причине, что у вас много операторов return. Если у вас есть один оператор return, вы будете использовать конструкторы else, которые здесь не нужны.

Как насчет случая, когда b1 == b2? (И если a == b1 и a == b2?)

Если это произойдет, то, вообще говоря, следующие два фрагмента кода могут иметь другое поведение:

if (a == b1) {
   /* do stuff here, and break out of the test */
} 
else if (a == b2) {
   /* this block is never reached */
} 

и:

if (a == b1) {
   /* do stuff here */
}
if (a == b2) {
   /* do this stuff, as well */
}

Если вы хотите четко очертить функциональность для разных случаев, используйте if-else или switch-case, чтобы сделать один тест .

Если вы хотите разную функциональность для нескольких случаев, используйте несколько if блоков в качестве отдельных тестов .

Это не вопрос «лучших практик», так и для определения того, есть ли у вас один тест или несколько тестов.

Это полностью зависит от состояния, которое вы тестируете. В вашем примере это не будет иметь никакого значения в конце концов, но, как наилучшая практика, если вы хотите, чтобы ОДИН из условий был в конечном счете выполнен, тогда вам лучше использовать if else

if (x > 1) {
    System.out.println("Hello!");
}else if (x < 1) {
    System.out.println("Bye!");
}

Также обратите внимание, что если первое условие имеет значение TRUE второй НЕ будет проверяться вообще, но если вы используете

if (x > 1) {
    System.out.println("Hello!");
}
if (x < 1) {
    System.out.println("Bye!");
}

Второе условие будет проверяться, даже если первое условие имеет значение ИСТИНА. В конечном итоге это может решить оптимизатор, но насколько я знаю, он ведет себя так. Также первый из них - тот, который должен быть написан и ведет себя так, поэтому он всегда лучший выбор для меня, если логика не требует иного.

НЕ функционально эквивалентны.

Единственный способ, который был бы функционально эквивалентен, - это если вы сделали оператор «if» для каждого возможного значения a (то есть: каждый возможный значение int, как определено в limits.h в C, используя INT_MIN и INT_MAX, или эквивалент в Java).

Оператор else позволяет вам покрывать все возможные оставшиеся значения без необходимости писать миллионы «if» -записей.

Кроме того, лучше использовать практику кодирования, если ... else if ... else, как и в случае с оператором switch / case, ваш компилятор будет называть вас предупреждением, если вы не предоставите «значение по умолчанию» «case case. Это не позволяет вам игнорировать недопустимые значения в вашей программе. например:

double square_root(double x) {
    if(x > 0.0f) {
        return sqrt(x);
    } else if(x == 0.0f) {
        return x;
    } else {
        printf("INVALID VALUE: x must be greater than zero");
        return 0.0f;
    }
}

Вы хотите набирать миллионы операторов if для каждого возможного значения x в этом случае? Сомневаюсь:)

Приветствия!

Я предпочитаю, если / else структуры, потому что гораздо легче оценить все возможные состояния вашей проблемы в каждом варианте вместе с переключателями. Это более надежное решение, которое я нахожу и быстрее отлаживаю, особенно когда вы выполняете несколько булевых оценок в слабо типизированной среде, например PHP, например, почему elseif является плохим (преувеличенным для демонстрации):

if(a && (c == d))
{
} elseif ( b && (!d || a))
{
} elseif ( d == a && ( b^2 > c))
{
} else {
}

Эта проблема имеет выше 4 ^ 2 = 16 булевых состояний, что просто демонстрирует эффекты слабого ввода, что еще хуже. Не так сложно представить три переменные состояния, три переменные проблемы, связанные с типом пути if ab elseif bc.

Оставить оптимизацию компилятору.

Ответ CanSpice правильный. Дополнительным соображением для эффективности является выяснение того, какое условие происходит чаще всего. Например, если a == b1 возникает только 1% времени, то вы получаете лучшую производительность, сначала проверяя другой случай.

Gir Loves Tacos ответ также хорош. Лучшая практика заключается в том, чтобы обеспечить охват всех случаев.

Ваше сравнение основывается на том факте, что тело операторов if возвращает управление из метода. В противном случае функциональность будет отличаться.

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

С операторами return в каждой ветви if.

В вашем коде у вас есть return заявления в каждом из условий if. Когда у вас есть такая ситуация, есть два способа написать это. Во-первых, как вы написали его в примере 1:

if (a == b1) {
   return c1;
} else if (a == b2) {
   return c2;
} else {
   return c11;
}

Другое следующее:

if (a == b1) {
   return c1;
}
if (a == b2) {
   return c2;
}
return c11; // no if or else around this return statement

Эти два способа написания кода идентичны.

Способ, которым вы написали код в примере 2, не будет компилироваться на C ++ или Java (и будет неопределенным поведением в C), поскольку компилятор не знает, что вы применили все возможные значения a, поэтому он считает, что есть путь кода через функцию, которая может привести вас к концу функции, не возвращая возвращаемое значение.

if (a == b1) {
   return c1;
}
if (a == b2) {
   return c2;
}
...
if (a == b11) {
   return c11;
}
// what if you set a to some value c12?

Без return операторов в каждой ветви if.

Без операторов return в каждой ветви if ваш код будет функционально идентичным только в том случае, если следующие утверждения верны:

1. Вы не изменяете значение из a в любой из ветвей if.
2. == является отношением эквивалентности (в математическом смысле), и ни один из b1 через b11 не находится в одном классе эквивалентности .
3. == не имеет побочных эффектов.

Чтобы уточнить дальнейшие abo ut point # 2 (а также точка # 3):

• == всегда является отношением эквивалентности в C или Java и никогда не имеет побочных эффектов.
• На языках, которые позвольте вам переопределить оператор ==, такой как C ++, Ruby или Scala, переопределенный оператор == не может быть отношением эквивалентности и может иметь побочные эффекты. Мы определенно надеемся, что тот, кто переопределяет оператор ==, был достаточно здравым, чтобы написать отношение эквивалентности, которое не имеет побочных эффектов, но нет никакой гарантии.
• В JavaScript и некоторых других языках программирования со свободным типом преобразования правила, есть случаи, которые встроены в язык, где == не является транзитивным или несимметричным. (В Javascript === является отношением эквивалентности.)

С точки зрения производительности, пример # 1 гарантированно не выполняет никаких сравнений после совпадения. Возможно, компилятор сможет оптимизировать # 2, чтобы пропустить дополнительные сравнения, но это маловероятно. В следующем примере это, вероятно, не может, и если строки длинны, дополнительные сравнения не являются дешевыми.

if (strcmp(str, "b1") == 0) {
  ...
}
if (strcmp(str, "b2") == 0) {
  ...
}
if (strcmp(str, "b3") == 0) {
  ...
}

Они потенциально делают разные вещи.

Если a равно b1 и b2, вы вводите два блока if. В первом примере вы только когда-либо вводите его. Я предполагаю, что первый пример выполняется быстрее, поскольку компилятор, вероятно, должен проверять каждое условие последовательно, поскольку к объекту могут применяться определенные правила сравнения. Возможно, они смогут оптимизировать их ... но если вы хотите, чтобы один из них был введен, первый подход более очевидный, с меньшей вероятностью приведет к ошибке разработчика или неэффективному коду, поэтому я определенно рекомендую это.

Я склонен думать, что использование else if проще в отношении кодовых изменений. Если кто-то должен был отрегулировать поток управления функции и заменил возврат с побочным эффектом или вызовом функции с try-catch, то else-if потерпит неудачу, если все условия действительно исключительны. Это действительно зависит от точного кода, с которым вы работаете, чтобы сделать общее мнение, и вам нужно кратко рассмотреть возможные компромиссы.

if и else if отличаются от двух последовательных операторов if. В первом случае, когда процессор принимает первую ветвь if, else if не будет проверяться. В двух последовательных операторах if, даже если первый if проверен и принят, следующий if также будет проверяться и принимать, если условие истинно.