Чи погані практики програмування `break 'та` continue`?

Мій начальник постійно згадує, що погані програмісти використовують breakі continueв циклі.

Я їх постійно використовую, бо вони мають сенс; дозвольте показати вам натхнення:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

Суть у тому, що спочатку функція перевіряє правильність умов, а потім виконує фактичну функціональність. IMO те саме стосується циклів:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

Я думаю, що це полегшує читання та налагодження; але я також не бачу недоліків.

При використанні на початку блоку, як зроблені перші перевірки, вони діють як передумови, тому це добре.

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

Ви можете прочитати документ Дональда Кнута 1974 р. " Структуроване програмування" із документом "Перейти до заяви" , в якому він обговорює різні способи використання, go toякі є структурно бажаними. Вони включають еквівалент breakта continueтвердження (багато застосувань go toу них були розроблені в більш обмежені конструкції). Ваш начальник тип називати Кнут поганим програмістом?

(Приклади наведені мене цікавлять. Як правило, breakі continueне люблять людей , які люблять один вхід і один вихід з будь-якої частини коду, і що така людина також хмуриться на кілька returnтверджень.)

Я не вірю, що вони погані. Ідея, що вони погані, походить із часів структурованого програмування. Це пов'язано з поняттям, що функція повинна мати одну точку входу та одну точку виходу, тобто лише одну returnна функцію.

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

Якщо ваша функція дуже коротка, якщо у вас є одна петля, або, в гіршому випадку, дві вкладені петлі, і якщо тіло циклу дуже коротке, то зрозуміло, що робити breakабо continueробити. Також зрозуміло, що returnроблять кілька заяв.

Ці питання розглядаються у "Чистому кодексі" Роберта К. Мартіна та у "Рефакторингу" Мартіна Фаулера.

Погані програмісти говорять в абсолютах (так само, як і Сіт). Хороші програмісти використовують найяскравіше можливе рішення (при всіх інших рівнях ).

Використання перерви та продовження часто ускладнює дотримання коду. Але якщо їх заміна робить код ще складніше слідувати, то це погані зміни.

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

Більшість людей вважають, що це погана ідея, оскільки поведінку нелегко передбачити. Якщо ви читаєте код і бачите, while(x < 1000){}що припускаєте, що він буде працювати до x> = 1000 ... Але якщо в середині є розриви, то це не відповідає дійсності, тому ви не можете довіряти своєму петля ...

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

Для себе, якби я збирався зробити цикл, який розірвався за більше ніж одна умова, я б while(x){}тоді переключив X на хибне, коли мені потрібно було вийти з ладу. Кінцевий результат був би таким же, і кожен, хто читає код, знав би уважніше придивитися до речей, які змінили значення X.

Так, ви можете [повторно] писати програми без заяв про перерви (або повернення з середини циклів, які роблять те саме). Але, можливо, вам доведеться ввести додаткові змінні та / або дублювання коду, які, як правило, ускладнюють розуміння програми. Паскаль (мова програмування) був дуже поганим, особливо для початківців програмістів саме з цієї причини. Ваш начальник, по суті, хоче, щоб ви запрограмували в контрольних структурах Паскаля. Якби у Ваших черевиках був Лінус Торвальдс, він, мабуть, показав вашому начальнику середній палець!

Є результат інформатики, який називається ієрархією управлінських структур Косараджу, яка починається з 1973 року, і про яку згадується у відомому документі Кнута про готи з 1974 року. .) Що довів С. Рао Косараджу в 1973 році, це те, що неможливо переписати всі програми, які мають багаторівневі перерви глибини n, в програми з глибиною розриву менше n без введення зайвих змінних. Але скажімо, що це лише суто теоретичний результат. (Просто додайте кілька додаткових змінних ?! Безумовно, ви можете це зробити, щоб догодити своєму начальнику ...)

Що набагато важливіше з точки зору інженерії програмного забезпечення - це нещодавніший документ Еріка С. Робертса з 1995 р. Під назвою Вихід з циклу та структуроване програмування: Повторне відкриття дискусії ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / LoopExits.pdf ). Робертс підсумовує кілька емпіричних досліджень, проведених іншими перед ним. Наприклад, коли групі студентів типу CS101 було запропоновано написати код функції, що реалізує послідовний пошук у масиві, автор дослідження сказав наступне про тих студентів, які використовували перерву / повернення / goto для виходу з послідовний цикл пошуку, коли елемент був знайдений:

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

Робертс також говорить, що:

Студенти, які намагалися вирішити проблему, не використовуючи явного повернення з циклу for for, пройшли набагато менше: лише семеро з 42 студентів, які намагалися використовувати цю стратегію, змогли створити правильні рішення. Цей показник представляє рівень успішності менше 20%.

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

Тут я також скажу, що документ Робертса набагато доступніший середньому програмісту, тому краще в першу чергу прочитати, ніж Книт. Він також коротший і охоплює більш вузьку тему. Ви, напевно, можете навіть рекомендувати його своєму начальнику, навіть якщо він керує, а не типом CS.

Я не розглядаю можливість використання жодної з цих поганих практик, але занадто багато їх використання в одному циклі повинно бути підставою для переосмислення логіки, яка використовується в циклі. Використовуйте їх економно.

Приклад, який ви подали, не потребує перерв і не продовжує:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

Моя «проблема» з чотирьох рядків у вашому прикладі полягає в тому, що вони всі на одному рівні, але вони роблять різні речі: деякі перерва, деякі продовжують ... Ви повинні прочитати кожен рядок.

У моєму вкладеному підході, чим глибше ви проходите, тим «кориснішим» стає код.

Але, якщо глибоко всередині ви знайдете причину, щоб зупинити цикл (крім основного стану), перерва чи повернення мали б це використовувати. Я вважаю за краще, щоб над використанням додаткового прапора, який повинен бути протестований у високому рівні. Перерва / повернення більш пряме; він краще заявляє про наміри, ніж встановлювати ще одну змінну.

"Поганість" залежить від того, як ви їх використовуєте. Я зазвичай використовую перерви в циклічних конструкціях ТІЛЬКИ, коли це врятує мені цикли, які неможливо зберегти за допомогою рефакторингу алгоритму. Наприклад, проїзд по колекції шукає предмет зі значенням у певному властивості, встановленому на true. Якщо все, що вам потрібно знати, - це те, що для одного з елементів було встановлено значення властивості true, як тільки ви досягнете цього результату, перерву добре перервати циклом належним чином.

Якщо використання перерви не зробить код особливо простішим для читання, скороченням циклу та збереженням циклів при обробці значним чином, то краще не використовувати їх. Я, як правило, кодую "найнижчий загальний знаменник", коли це можливо, щоб переконатися, що кожен, хто йде за мною, може легко подивитися на мій код і зрозуміти, що відбувається (я не завжди в цьому успішний). Перерви це зменшують, оскільки вони вводять непарні точки входу / виходу. Зловживані вони можуть вести себе дуже схоже на несанкціоновану заяву "goto".

Абсолютно ні ... Так використання gotoпогано, оскільки воно погіршує структуру вашої програми, а також дуже важко зрозуміти потік управління.

Але використання висловлювань як breakі continueє абсолютно необхідними в наші дні і зовсім не вважається поганою практикою програмування.

А також не так складно зрозуміти контрольний потік при використанні breakі continue. У конструкціях , як switchв breakзаяві абсолютно необхідно.

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

Частково ця складність відображається в тому, що можна концептуально міркувати про ваш код.

Чесно кажучи, ваш другий код не очевидний. Що це робить? Чи продовжується "продовження", чи це "наступний цикл"? Я поняття не маю. Принаймні ваш перший приклад зрозумілий.

Я б замінив ваш другий фрагмент коду

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

не з будь-яких причин лаконічності - я насправді думаю, що це легше читати і комусь зрозуміти, що відбувається. Взагалі кажучи, умови для петель повинні міститися виключно в тих умовах, що не є засміченими по всьому тілу. Однак є деякі ситуації, коли breakі continueможуть допомогти читати. breakбільше, ніж continueя можу додати: D

Я не згоден з вашим начальником. Є належні місця для використання breakта continueїх використання. Насправді причина того, що до сучасних мов програмування були введені винятки та поводження з винятками, є те, що не можна вирішити кожну проблему просто structured techniques.

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

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

З іншого боку примітка

Мені особисто не подобається використання ( flag == true )в умовних умовах, оскільки якщо змінна вже булева, то ви вводите додаткове порівняння, яке має відбутися, коли значення булевого має відповідь, яку ви хочете - якщо, звичайно, ви не впевнені, що ваш компілятор буде оптимізуйте це додаткове порівняння.

Я згоден з вашим начальником. Вони погані, оскільки виробляють методи з високою цикломатичною складністю. Такі методи важко читати і важко перевірити. На щастя, тут є просте рішення. Витягніть тіло циклу в окремий метод, де "продовження" стає "поверненням". "Повернення" краще, тому що після "повернення" воно закінчиться - немає проблем про місцеву державу.

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

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

Я думаю, що це проблема лише тоді, коли вкладається глибоко всередині декількох петель. Важко дізнатися, до якої петлі ви зламаєтесь. Можливо, буде важко йти за продовженням, але я думаю, що справжній біль виникає через перерви - за логікою може бути важко дотримуватися.

Поки вони не використовуються як замасковані готи, як у наступному прикладі:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

Я з ними добре. (Приклад видно у виробничому коді, мех)

Мені не подобається жоден із цих стилів. Ось що я віддаю перевагу:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

Мені дуже не подобається використовувати returnфункцію переривання функції. Це відчувається як зловживання return.

Використання breakтакож не завжди зрозуміло для читання.

Ще краще може бути:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

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

(Весь наведений вище код є псевдокодом)

Ні. Це спосіб вирішити проблему. Є й інші способи її вирішення.

Багато сучасних основних мов (Java, .NET (C # + VB), PHP, пишіть власні) використовують "break" і "продовжити" для пропуску циклів. Вони обидва речення "структуровані гот (и)".

Без них:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

З ними:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

Зауважте, що "перерва" та "продовження" код коротший і зазвичай перетворюється "в той час як" речення на "за" або "передбачати" пропозиції.

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

Я фактично працюю в деяких проектах, де обов'язково було використовувати ці речення.

Деякі розробники можуть подумати, що вони не потрібні, але гіпотетичні, якщо нам довелося їх видалити, ми повинні видалити "в той час" і "робити поки" ("повторюйте поки", ви, паскаль, хлопці) також ;-)

Висновок, навіть якщо я вважаю за краще не використовувати їх, я вважаю, що це варіант, а не погана практика програмування.

Я не проти continueі breakв принципі, але думаю, що це дуже низькі конструкції, які дуже часто можуть бути замінені чимось ще кращим.

Я використовую C # як приклад, розглянемо випадок, коли хочеться перебрати колекцію, але ми хочемо лише елементів, які виконують деякий предикат, і ми не хочемо робити більше, ніж максимум 100 ітерацій.

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

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

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

Можливо, дзвінки «Де та приймати» навіть у цьому методі не повинні бути. Можливо, цю фільтрацію слід зробити перед тим, як колекція передається цьому методу. У будь-якому випадку, відходячи від речей низького рівня та зосереджуючись більше на власне логіці бізнесу, стає зрозуміліше, що нас актуально цікавить. Стає простіше розділити наш код на згуртовані модулі, які більше дотримуються передового дизайнерського практику тощо. на.

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

Code Complete має хороший розділ про використання gotoта кілька повернень з рутини або циклу.

Взагалі це не погана практика. breakабо continueточно скажіть, що буде далі. І я з цим згоден.

Стів МакКоннелл (автор Code Complete) використовує майже ті ж приклади, що і ви, щоб показати переваги використання різних gotoоператорів.

Однак надмірне використання break або continueможе призвести до складного та незрозумілого програмного забезпечення.