Использование break в цикле for - плохая практика? [закрыто]

Использование breakоператора внутри forцикла - плохая практика ?

Скажем, я ищу значение в массиве. Сравните внутри цикла for и, когда значение найдено, break;чтобы выйти из цикла for.

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

Я спрашиваю в контексте обычного цикла for на C или C ++.

PS: Руководство по кодированию MISRA не рекомендует использовать break.

Здесь много ответов, но я еще не видел этого:

Большинство «опасностей», связанных с использованием breakили continueв цикле for, устраняются, если вы пишете аккуратные, легко читаемые циклы. Если тело вашего цикла охватывает несколько длин экрана и имеет несколько вложенных субблоков, да, вы можете легко забыть, что некоторый код не будет выполняться после разрыва. Однако если цикл короткий и по существу, цель оператора break должна быть очевидна.

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

Нет, перерыв - правильное решение.

Добавление логической переменной затрудняет чтение кода и добавляет потенциальный источник ошибок.

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

Использование breakкак continueв forцикле - это нормально.

Это упрощает код и улучшает его читаемость.

В отличие от плохой практики, Python (и другие языки?) forРасширил структуру цикла, поэтому его часть будет выполняться только в том случае, если цикл не работает break .

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

Вывод:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

Эквивалентный код без breakи того под рукой else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Нет ничего плохого в использовании оператора break, но вложенные циклы могут сбивать с толку. Для улучшения читаемости многие языки ( по крайней мере, Java ) поддерживают разбиение на метки, что значительно улучшит читаемость.

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

Я скажу, что операторы break (и return) часто увеличивают цикломатическую сложность, что затрудняет доказательство того, что код делает правильные вещи во всех случаях.

Если вы планируете использовать перерыв при повторении последовательности для определенного элемента, вы можете пересмотреть структуру данных, используемую для хранения ваших данных. Использование чего-то вроде Set или Map может дать лучшие результаты.

break - вполне приемлемый оператор (как и continue , кстати). Все дело в удобочитаемости кода - пока у вас нет слишком сложных циклов и тому подобного, все в порядке.

Не то чтобы они были из той же лиги, что и Гото . :)

Общее правило: если следование правилу требует от вас сделать что-то более неудобное и трудное для чтения, а затем нарушить правило, нарушите правило.

В случае зацикливания до тех пор, пока вы что-то не найдете, вы столкнетесь с проблемой различения найденного и не найденного, когда вы выберетесь. То есть:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Итак, хорошо, вы можете установить флаг или инициализировать "найденное" значение нулевым. Но

Вот почему я предпочитаю выполнять поиск в функциях:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Это также помогает не загромождать код. В основной строке «find» становится единственным оператором, а когда условия сложные, они записываются только один раз.

Это зависит от языка. Хотя вы можете проверить здесь логическую переменную:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

это невозможно сделать при обходе массива:

for element in bigList: ...

В любом случае breakсделал бы оба кода более читабельными.

В вашем примере вы не знаете количество итераций для цикла for . Почему бы не использовать то время как цикл вместо, что позволяет число итераций быть неопределенными в начале?

Именно поэтому не стоит использовать перерыв statemement в целом, так как цикл может быть лучше сказать , как в то время цикла.

Я согласен с другими, кто рекомендует использовать break. Возникает очевидный вопрос: почему кто-то может рекомендовать иное? Что ж ... когда вы используете break, вы пропускаете остальную часть кода в блоке и оставшиеся итерации. Иногда это вызывает ошибки, например:

• ресурс, полученный наверху блока, может быть освобожден внизу (это верно даже для блоков внутри forциклов), но этот шаг освобождения может быть случайно пропущен, когда «преждевременный» выход вызван breakоператором (в «современном» C ++, "RAII" используется для надежной и безопасной обработки исключений: в основном деструкторы объектов надежно освобождают ресурсы независимо от того, как выходит из области видимости)

• кто-то может изменить условный тест в forоператоре, не заметив других делокализованных условий выхода

• В ответе ndim отмечается, что некоторые люди могут избегать breaks для поддержания относительно согласованного времени выполнения цикла, но вы сравнивали breakс использованием логической переменной управления ранним выходом, где это не выполняется

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

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

Его вполне допустимо использовать break- как отмечали другие, он нигде не в той же лиге, что и goto.

Хотя вы можете использовать vFoundпеременную, когда хотите проверить вне цикла, было ли значение найдено в массиве. Также с точки зрения ремонтопригодности может быть полезно наличие общего флага, сигнализирующего о критериях выхода.

Я провел некоторый анализ кодовой базы, над которой сейчас работаю (40 000 строк JavaScript).

Я нашел только 22 breakутверждения, из них:

• 19 использовались внутри switchоператоров (всего у нас всего 3 оператора switch!).
• 2 использовались внутри forциклов - код, который я сразу классифицировал как подлежащий рефакторингу в отдельные функции и замененный returnоператором.
• Что до последнего breakвнутреннего whileцикла ... Я побежал git blameпосмотреть, кто написал эту хрень!

Итак, согласно моей статистике: если breakиспользуется вне switch, это запах кода.

Я тоже искал continueзаявления. Не нашел.

Я не вижу причин, по которым это было бы плохой практикой, ПРЕДОСТАВЛЯЕМЫЙ, когда вы хотите завершить обработку STOP на этом этапе.

Во встроенном мире есть много кода, который использует следующую конструкцию:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

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

Мое личное мнение состоит в том, что нет ничего плохого в написании цикла таким образом, если приняты соответствующие меры, чтобы не допустить бесконечного пребывания в цикле.

Зависит от вашего варианта использования. Есть приложения, в которых время выполнения цикла for должно быть постоянным (например, чтобы удовлетворить некоторым временным ограничениям или скрыть внутренние данные от атак, основанных на времени).

В этих случаях имеет смысл даже установить флаг и проверять значение флага только ПОСЛЕ того for, как фактически будут выполнены все итерации цикла. Конечно, все итерации цикла for должны запускать код, который занимает примерно одинаковое время.

Если вас не волнует время выполнения ... используйте break;и, continue;чтобы код было легче читать.

В правилах MISRA 98, которые используются в моей компании в C-dev, оператор break не должен использоваться ...

Изменить: перерыв разрешен в MISRA '04

Конечно, break;это решение для остановки цикла for или цикла foreach. Я использовал его в php в foreach и for loop и обнаружил, что работает.

Я не согласен!

Почему вы игнорируете встроенные функции цикла for, чтобы создать свои собственные? Не нужно изобретать велосипед.

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

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

или если вам нужно сначала обработать строку

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

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

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Или, если ваше состояние сложное, вы также можете убрать этот код!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

«Профессиональный кодекс», изобилующий перерывами, мне не кажется профессиональным. Похоже на ленивое кодирование;)