Условия в циклах, передовой практике?

Question

Скажем, у меня есть цикл, как это:

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
     continue; 
    } 
    doSomeOtherStuff(); 
} 

Versus ...

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
    } 
    else 
    { 
     doSomeOtherStuff(); 
    } 
} 

Есть ли какой-либо причине, чтобы использовать один над другим? Или это просто личное предпочтение?
Основным языком, на который я прошу это, является Java, но, я думаю, это относится и к большинству других.

Answer 1

Технически, нет, но я нахожу второй красивее для этого конкретного случая.

Answer 2

Я бы предпочел второй синтаксис.

Старайтесь избегать операторов продолжения, где это возможно. Это делает код путь более трудно следовать, и для этого трудно отлаживать

Answer 3

Я предпочитаю второй конструкт ...

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
     //lets say lot of code 
     //.. 
     //... 
     //... 
     //... 
     continue; 
    } 
    else 
    { 
     doSomeOtherStuff(); 
    } 
} 

Допустим, у вас было много кода перед continue. Это сразу бросается в глаза, просто посмотрев

else 
    { 
     doSomeOtherStuff(); 
    } 

тем он не выполняется безоговорочно.

Answer 4

Для меня, это зависит от того, что раскол между then и относительной else ветви размеров: если один массово больше, чем другие, и тем меньше из них представляет собой логически исключительную ситуацию, я ставлю короче один в then, и добавьте continue; когда они примерно равны, как по размеру, так и по логическому потоку, я держу их в своих собственных ветвях then и else.

for (String tok : tokens) { 
    if (isKeyword(tok)) { 
     output.write(tok); 
     continue; 
    } 
    // Do some massive processing of non-keyword tokens here 
    // This block goes on... 
    // and on... 
    // and on... You get the idea 
} 

против

for (String op : operators) { 
    if (isAdditive(op)) { 
     // Do something for additive ops 
    } else { 
     // Do something for non-additive ops 
    } 
} 

Answer 5

В данном конкретном случае, я согласен со всеми остальными, что второй является предпочтительным. Но бывают случаи, когда я пойду первым. Если DoSomething() действительно были только одним вызовом, а i == someCondition - это кромка края, а doSomeOtherStuff() были на самом деле 20 строк кода вместо этого одного вызова, тогда я бы предпочел использовать continue. В этом сценарии я прочитал его как «во-первых, давайте позаботимся об этом случае с одним краем. Хорошо, теперь давайте сделаем настоящий материал».

Конечно, можно было бы аргументировать if-else, перефразировав мою интерпретацию на «если мы в краевом случае делаем это, а то и делаем реальные вещи». Но это означает, что все эти 20 строк в настоящее время одно гнездое глубже, и для меня более читаемо сначала позаботиться о краевых случаях, а затем сосредоточиться на общем пути.

Answer 6

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

Просто чтобы дать вам ссылку:

JSF ++ (Правило 190) и Мишр C (Правило 57) говорят:

продолжените заявление не должен быть использован.

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

Мишра платный, но JSF ++ можно скачать бесплатно здесь:

http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc

Это на C++, но многие правила могут быть применены и к другим языкам. Это стоит чтения!

Answer 7

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

Скажет, например, у вас есть много, и я имею в виду много условий внутри вашего цикла, где, имея много if заявлений на самом деле влияет на читаемость через отступ:

for (int i = 0 ; i < n ; i++) 
{ 
    if (obj[i]) 
    { 
     doSomething(); 
     if (someOtherCondition() 
     { 
      //........... 
                if (/* some levels down */) 
                { 

                } 
      //..... 
     } 
    } 
} 

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

Таким образом, вы можете реорганизовать и сделать его намного более читаемым с:

for (int i = 0 ; i < n ; i++) 
{ 
    if (!obj[i]) 
    { 
     continue; 
    } 
    doSomething(); 
    if (!someOtherCondition() 
    { 
     continue; 
    } 
    //........... 
} 

Answer 8

Я думаю, что это в большей степени зависит от того, что вы делаете.

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

for (int i = 0 ; i < n ; i++) 
{ 
    if(obj[i] != null && obj[i].instanceOf("A")) { 
     doSomething(); 
    } else if(obj[i] != null && obj[i].instanceOf("B"){ 
     doSomethingElse(); 
    } 
} 

сейчас стало ясно, что извлекая первое условие в

if(obj[i] == null) { 
    continue; 
} 

может сохранить некоторую путаницу так как этот цикл будет усилен. Я часто использую эту тактику для тестирования параметров метода и возвращаюсь раньше или бросаю исключение.

Также (это полностью отвлеченный, а не часть ответа вообще!), Я бы сказал, что если вы когда-нибудь увидите сбалансированное состояние «Truly», вы можете серьезно подумать о своем дизайне OO. Если йоЗотеЬЫпд и someOtherCondition было то, что похожи, они, вероятно, следует различных реализаций метода определенной в базовом классе или интерфейсе, что приводит к этому коду:

for (int i = 0 ; i < n ; i++) 
{ 
    obj[i].doSomething(); 
}