"если 'VS" еще, если " - PullRequest
       65

"если 'VS" еще, если "

11 голосов
/ 24 сентября 2010

Мне сказали, что использование операторов "if" предпочтительнее из-за более сложной отладки кода, когда используется "else if"?Есть ли доля правды в этом утверждении?

Ответы [ 21 ]

0 голосов
/ 04 октября 2010

ответ, данный JDV, кажется правильным. Я пришел сюда, чтобы найти ответ самого симларского типа. Однако ответ, выбранный владельцем вопроса, не является правильным / правильным. Правильный / правильный ответ касается ранних возвратов и четких стилей, а также того факта, что вложение слишком большого количества операторов if-then-else в общем случае не является хорошим стилем программирования. И впредь отлаживать плохо написанный код всегда сложнее.

ЗАКЛЮЧЕНИЕ: условный код должен быть максимально четким / простым, чтобы на этапе программирования или на этапе отладки человек мог легко управлять задействованными переменными.

0 голосов
/ 25 сентября 2010

Я главный программист, и иногда мои подчиненные меня неправильно понимают.Когда я говорил о конкретном случае, много раз они воспринимали его как «правило» и пытались применять его повсеместно в кодовой базе.Я не уверен, если это ваш случай или нет, или, может быть, когда-то ваш начальник был моим подчиненным?

По поводу вопроса, else if хорошо для меня, но когда их не слишком много, потому что1004 * заставляет вас читать все выражения над ними, чтобы понять, когда код внутри будет выполнен.

0 голосов
/ 25 сентября 2010

Это зависит от того, чего вы пытаетесь достичь. Оба являются приемлемыми формами кодирования, это зависит только от того, что вы делаете. Например, если вы хотите убедиться, что каждое сравнение проверено и возможность запуска всего кода, вы должны использовать единственную конструкцию if:

if(condition1IsTrue) {
    methodThatMustRun1();
}

if(condition2IsTrue) {
    methodThatMustRun2();
}

... etc

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

Если вы хотите запустить только один блок кода из нескольких вариантов, тогда вам следует использовать конструкцию if else, предпочтительно в порядке наиболее распространенных, встречающихся в наименьших:

if(condition1IsTrue) {
    mostCommonMethodToRun();
} else if (separateConditionToCheckInCaseFirstFails) {
    nextMostCommonScenarioMethodToRun();
} else if (...) {
    ... etc
}

Во втором примере не более проверяются все условия, но потенциально проверяется только одно. Однако выполняется ровно один блок кода (при условии, что у вас есть действие по умолчанию, если ни одно из условий не оценивается как true).

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

Однако ваш босс МОЖЕТ быть идиотом, если он догматично говорит, что вы никогда не должны программировать в if else конструкциях.

0 голосов
/ 25 сентября 2010

Форма «оператора if»:

if (condidtion1)
   statement1;
else
   statement2;

Одной из допустимых форм оператора является «оператор if».Давайте превратим «Statement2» выше в «If Statement» if (condition2) statement3;

if (condition1)
   statement1;
else if (condition2)
   statement3;

Пробел и позиционирование только для вашей выгоды (удобочитаемость).Сам компилятор ничего не знает о 'else if'.

Это демонстрирует, что 'if' и 'else if' не одно и то же.'else if' является составным оператором.

Другая допустимая форма для оператора - это блок операторов, заключенный в квадратные скобки {}.Вот почему вы часто (обычно) видите скобки в выражении «если».Использовать ли их в одном выражении или нет - это просто вопрос стиля.

Причина использования «else if» заключается в том, что вам не нужно обрабатывать выражения «condition», которые, как вы знаете, оценят как false,Вы знаете это из-за других условий, которые вы уже проверили.

Возможно, ваш начальник говорит, что вы можете ошибиться в этих предположениях и что утверждения «иначе, если» могут скрывать скрытые ошибки.Я полагаю, что это, безусловно, возможно.Это, похоже, не стоит накладных расходов.

Что он может сказать о «операторе переключения»?

0 голосов
/ 25 сентября 2010

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

0 голосов
/ 25 сентября 2010

Это намного лучше, чем:

if (a=1) then {
  DoThis;
  EXIT;  // Not sure if this works in your language, but you know what I mean...
}
if (a=2) then {
  DoThis;
  EXIT;
}
if (a=3) then {
  DoThis;
  EXIT;
}
0 голосов
/ 24 сентября 2010

Вы сравниваете

if (a=b) do this;
if (a=c) do this;
if (a=d) do this;

Кому:

if (a=b) do this;
else if (a=c) do this;
else if (a=d) do this;

1) первый пример сложнее отладить, потому что у вас нет естественного рабочего процесса для кода, как во втором примере.

2) как указал Джейсон, первый пример работает иначе, чем второй, поскольку все три оператора if будут проверяться, несмотря ни на что, тогда как второй пример прекратит тестирование, когда оно станет истинным.

tl; dr: Ваш начальник неправ, несмотря на то, что у него также есть доступ в Интернет.

0 голосов
/ 24 сентября 2010

Почему бы вам не попробовать поиск n, заменяя все остальные ifs на ifs в вашем коде?он будет скомпилирован, но он будет выполняться так, как вам нужно, если вам повезет ...

Это просто не то же самое, и есть причина, почему есть If и почему есть Else IF.

Пример:

if(3<5) {
 print('blah');
} else if(4<5) {
 print('blub');
}
// blah

if(3<5) {
 print('blah');
} 
if(4<5) {
 print('blub');
}
// blahblub

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

есть также оператор switch.

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

Я бы даже сказал, что для каждого варианта использования существует одна оптимальная структура управления!

рассмотрим эти примеры:

if(money > 2000) {
 switch ($what-car-does-my-wife-want) {
     case "ferrari":
         echo "buying a ferrari";
         break;
     case "chevvy":
         echo "buying a chevvy";
         break;
     case "bmw":
         echo "buying a bmw";
         break;
 }

} else {
 echo "i better not buy a new car";
}
if(money > 5000) {
 echo "wow i can buy a lot of other things too!";
} else if(3000) {
 echo "wow that is a lot of money but i wish i had 5000!";
}

единственное, что вы можете сделать и какиевопрос стиля заменяет

if(money > 5000) {
 echo "wow i can buy a lot of other things too!";
} else if(money > 3000) {
 echo "wow that is a lot of money but i wish i had 5000!";
}

на

if(money > 5000) {
 echo "wow i can buy a lot of other things too!";
} else { 
    if(money > 3000) {
     echo "wow that is a lot of money but i wish i had 5000!";
    }
}

но я думаю, что это не то, что вы спросили?

0 голосов
/ 24 сентября 2010

если «иначе, если» является не предпочтительной конструкцией, то почему практически каждый современный язык обеспечивает это?Я думаю, что у вас все в порядке с дальнейшим использованием else ifs ... кроме того - к тому времени, когда он попадает в сборку, все равно это прыжок / переход;)

0 голосов
/ 24 сентября 2010

Обе формы требуют одинакового усилия по отладке. Я бы осмелился сказать, что операторы «else if» на самом деле облегчают отладку ...

Кроме того, операторы «else if» повышают производительность, поскольку вашей программе не нужно проверять условия, которые на самом деле являются взаимоисключающими!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...