Плохо ли использовать break в цикле for?

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

Большинство «опасностей», связанных с использованием 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.')

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

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

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;
}

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

В использовании оператора 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) часто увеличивают цикломатическую сложность, что затрудняет доказательство кода. делает правильную вещь во всех случаях.

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

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

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

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

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

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

for element in bigList: ...

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

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

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

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

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

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

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

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

Следовательно, нет необходимости использовать оператор break в целом, так как цикл лучше описать как цикл while.

Совершенно правильно использовать break - как указывали другие, он нигде не находится в той же лиге, что и goto.

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

Я не вижу причин, по которым это было бы плохой практикой, ПРИ УСЛОВИИ, что вы хотите завершить обработку STOP в этот момент.

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

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

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

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

Я также искал continue утверждений. Не нашел.

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

    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 и нашел работу.

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

Почему вы игнорируете встроенную функциональность цикла 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]);
}

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