Чи погана практика використовувати перерву в циклі for? [зачинено]

Чи погана практика використовувати breakоператор у forциклі ?

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

Це погана практика? Я бачив використану альтернативу: визначте змінну vFoundта встановіть її як true, коли знайдено значення та перевірте vFoundв forумові заяви. Але чи потрібно створити нову змінну саме для цієї мети?

Я прошу в контексті нормального C або C ++ для циклу.

PS: Вказівки щодо кодування MISRA не рекомендують використовувати перерви.

Тут багато відповідей, але я цього ще не бачив:

Більшість «небезпеки» , пов'язаних з використанням breakабо continueв циклі зведені на немає , якщо ви напишете акуратні, легко читаються петлі. Якщо тіло вашого циклу охоплює кілька довжин екрана і має кілька вкладених підблоків, так, ви можете легко забути, що якийсь код не буде виконаний після перерви. Якщо, однак, цикл короткий і до точки, мета заяви перерви повинна бути очевидною.

Якщо цикл стає занадто великим, замість цього використовуйте один або кілька добре названих функціональних викликів у циклі. Єдина реальна причина уникати цього - це обробка вузьких місць.

Ні, перерва - це правильне рішення.

Додавання булевої змінної робить код важчим для читання та додає потенційне джерело помилок.

Ви можете знайти всілякі професійні коди із заявами про "розрив". Це абсолютно доцільно використовувати це, коли це необхідно. У вашому випадку цей варіант кращий, ніж створення окремої змінної лише з метою виходу з циклу.

Використання 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.')

Немає нічого поганого в використанні заяви про перерву, але вкладені петлі можуть заплутатися. Для поліпшення читабельності багато мов ( принаймні 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 - це цілком прийнятне для використання твердження (так продовжується , btw). Вся справа в читабельності коду - доки у вас немає занадто складних циклів і подібного, це добре.

Це не так, як вони були тією ж лігою, що й Гото . :)

Загальне правило: Якщо дотримання правила вимагає від вас зробити щось більш незручне і важке для читання, то порушуючи правило, тоді порушуйте правило.

У разі циклічного циклу, поки ви щось не знайдете, ви стикаєтеся з проблемою розрізнення знайденого проти не знайденого, коли ви виходите. Це є:

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

Це також допомагає розмикати код. У головному рядку "знайти" стає єдиним твердженням, а коли умови складні, вони записуються лише один раз.

Це залежить від мови. Хоча ви можете перевірити булеву змінну тут:

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

це неможливо зробити при ітерації над масивом:

for element in bigList: ...

У будь-якому разі, breakзробить обидва коди читабельнішими.

У вашому прикладі ви не знаєте кількості ітерацій циклу for . Чому б не використовувати натомість цикл while, що дозволяє визначити кількість ітерацій на початку?

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

Я згоден з іншими, хто рекомендує використовувати break. Очевидний наслідковий питання - чому хтось рекомендував би інакше? Ну ... коли ви використовуєте перерву, ви пропускаєте решту коду в блоці та інші ітерації. Іноді це викликає помилки, наприклад:

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

• хтось може змінити умовний тест у forвиписці, не помітивши, що існують інші робокалізовані умови виходу

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

Раз у раз люди, що спостерігають за такими помилками, розуміють, що їх можна запобігти / пом'якшити цим правилом "без перерв" ... дійсно, існує ціла відповідна стратегія "безпечнішого" програмування під назвою "структуроване програмування", де кожна функція повинна мати також єдина точка входу та виходу (тобто немає переходу, раннього повернення). Це може усунути деякі помилки, але безперечно вводить інші. Чому вони це роблять?

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

Це цілком справедливо для використання break- як зазначали інші, він ніде не знаходиться в одній лізі, як goto.

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

Я зробив деякий аналіз кодової бази, над якою зараз працюю (40 000 рядків JavaScript).

Я знайшов лише 22 breakзаяви :

• 19 використовувались у внутрішніх switchоператорах (у нас всього 3 оператори переключення!).
• 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, заява про перерву не повинна використовуватися ...

Редагувати: перерва дозволена в MISRA '04

Звичайно, break;це рішення зупинити цикл for або петлі foreach. Я використовував його в php в foreach і for loop і виявив, що працює.

Я не погоджуюсь!

Чому б ви ігнорували вбудовану функціональність циклу 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]);
}

"Професійний кодекс", який пронизаний перервами, для мене насправді не звучить як професійний код. Це звучить як ліниве кодування;)