Чи слід перемістити умову перерви у поле стану, якщо можливо, всередині циклу for-loop? [зачинено]

Іноді мені потрібні петлі, для яких потрібен перерва:

for(int i=0;i<array.length;i++){
    //some other code
    if(condition){
        break;
    }
}

Я відчуваю себе незручно писати

if(condition){
    break;
}

тому що вона споживає 3 рядки коду. І я виявив, що цикл можна переписати так:

                                   ↓
for(int i=0;i<array.length && !condition;i++){
    //some other code
}

Отже, моє запитання полягає в тому, чи корисна практика переміщення умови в поле стану, щоб зменшити рядки кодів, якщо це можливо?

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

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

Я не купую аргумент про те, що "він споживає 3 рядки коду", і, отже, це погано. Зрештою, ви можете просто написати це як:

if (condition) break;

і просто споживайте один рядок.

Якщо ifз'являється на півдорозі через цикл, це, звичайно, має існувати як окремий тест. Однак якщо цей тест з’являється в кінці блоку, ви створили цикл, який має тест продовження на обох кінцях циклу, можливо, додаючи складності коду. Будьте в курсі, що іноді if (condition)тест може мати сенс лише після виконання блоку.

Але якщо припустити, що це не так, застосувавши інший підхід:

for(int i=0;i<array.length && !condition;i++){
    //some other code
}

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

Тут, звичайно, немає правильної відповіді. Тож знайте про мовні фрази мови, про умови кодування вашої команди і т. Д. Але, в цілому, я б застосував єдиний тестовий підхід, коли це має функціональний сенс.

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

forПетля просто є вказівка перебору значень в циклі. Кодування умови розриву всередині цього просто затуманює логіку ІМО.

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

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

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

forпетлі призначені для ітерації над чим-небудь ¹ - вони не просто lol-давайте-тягнемо-який-небудь-випадковий-речі-з-в-body-and-put-them-in-the-loop-header - три вирази мають дуже конкретні значення:

• Перший - для ініціалізації ітератора . Це може бути індекс, вказівник, об’єкт ітерації чи будь-що інше - доки він використовується для ітерації .
• Друга - для перевірки, чи ми досягли кінця.
• Третє - для просування в ітераторі.

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

Отже, вам потрібно запитати себе - чи є ваша умова щодо керування ітерацією чи логікою всередині циклу? Швидше за все, мова йде про логіку всередині циклу - тому його слід перевіряти всередині циклу, а не в заголовку.

¹ На відміну від інших циклів, які "чекають", щоб щось сталося. for/ foreachЦикл повинен мати поняття «список» елементи для ітерації по - навіть якщо цей список ледачий або нескінченний або реферату.

Я рекомендую використовувати версію з if (condition). Це легше читати і простіше налагоджувати. Написання 3 додаткових рядків коду не зламає ваші пальці, але спростить наступну людину зрозуміти ваш код.

Якщо ви повторюєте колекцію, де слід пропустити певні елементи, рекомендую новий варіант:

• Фільтруйте свою колекцію перед ітерацією

І Java, і C # роблять це порівняно тривіально. Я не був би здивований, якби C ++ мав можливість зробити ітератор фантазії, щоб пропустити певні елементи, які не застосовуються. Але це дійсно лише варіант, якщо ваша обрана мова підтримує її, і причина, яку ви використовуєте, breakполягає в тому, що існують умови щодо того, обробляєте ви елемент чи ні.

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

• Легше зрозуміти, коли цикл закінчується рано

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

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

У цій ситуації я рекомендую наступні вказівки в порядку уподобання:

• Фільтруйте колекцію, щоб усунути необхідність, breakякщо це можливо
• Складіть умовну частину умов для циклу
• Помістіть умовні breakелементи у верхній частині петлі, якщо це можливо
• Додайте багаторядковий коментар, привертаючи увагу до перерви, і чому вона існує

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

Я настійно рекомендую не менше здивуватися, якщо ви не отримаєте суттєвої вигоди в іншому випадку.

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

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

for(int i=0;i<array.length&&!condition;i++)

Якщо ви хочете використовувати цей стиль , незалежно, я рекомендую зміна частин for(int i=0;i<і ;i++)які говорять мозку читача , що це стандартне цикл.

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

for(int i=0;i<array.length&&!((someWidth.X==17 && y < someWidth.x/2) || (y == someWidth.x/2 && someWidth.x == 18);i++)

Тож якщо ви вирішите піти з собою if- breakвас охоплюють. Але якщо ви вирішили піти з forумовами, вам доведеться використовувати суміш умов if- breakі - for. Для того щоб бути послідовними, вам доведеться переміщувати умови вперед-назад між умовамиfor та if- breakколи умови змінюються.

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

Досягнувши успіху в "зменшенні рядків коду" тут, ви можете продовжити його перегляд

for(int i=0;i<array.length;i++){
    // some other code
    if(condition){
        break;
    }
    // further code
}

і застосувати те саме перетворення, доходячи до

for(int i=0;i<array.length && !condition;i++){
    // some other code
    // further code
}

Що є недійсним перетворенням, як ви тепер беззастережно робите further codeтам, де раніше цього не робили.

Набагато безпечніша схема трансформації полягає у вилученні some other codeта оцінці conditionокремої функції

bool evaluate_condition(int i) // This is an horrible name, but I have no context to improve it
{
     // some other code
     return condition;
}

for(int i=0;i<array.length && !evaluate_condition(i);i++){
    // further code
}

TL; DR Робіть все, що читається найкраще у ваших конкретних обставинах

Візьмемо цей приклад:

for ( int i = 1; i < array.length; i++ ) 
{
    if(something) break;
    // perform operations
}

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

for ( int i = 1; i < array.length && !something; i++ )

Потім знову, залежно від того, чи somethingможна встановити trueперед циклом, але не всередині нього, це може запропонувати більше ясності:

if(!something)
{
    for ( int i = 1; i < array.length; i++ )
    {...}
}

А тепер уявіть це:

for ( int i = 1; i < array.length; i++ ) 
{
    // perform operations
    if(something) break;
    // perform more operations
}

Ми надсилаємо туди дуже чітке повідомлення. Якщо somethingпід час обробки масиву стає істинним, тоді відмовтеся від усієї операції. Для того, щоб перенести чек у поле стану, вам потрібно виконати:

for ( int i = 1; i < array.length && !something; i++ ) 
{
    // perform operations
    if(!something)
    {
        // perform more operations
    }
}

Можливо, "повідомлення" затуманилося, і ми перевіряємо стан відмови в двох місцях - що робити, якщо умова відмови зміниться, і ми забудемо одне з цих місць?

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

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

Хоча це може бути привабливим, оскільки ви бачите всі умови у заголовку циклу і breakможуть бути заплутаними у великих блоках, forцикл - це шаблон, де більшість програмістів очікують циклічного перегляду певного діапазону.

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

Часто хорошою альтернативою є використання whileабо do {} whileциклу, який перевіряє обидві умови, припускаючи, що ваш масив має принаймні один елемент.

int i=0
do {
    // some other code
    i++; 
} while(i < array.length && condition);

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

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

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

array.find(item -> item.valid)

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

Мало причин, на мою думку, що говорить, не слід.

1. Це знижує читабельність.
   
2. Вихід може бути не однаковим. Однак це можна зробити за допомогою do...whileциклу (не while), оскільки умова перевіряється після виконання деякого коду.
   

Але поверх цього, врахуйте це,

for(int i=0;i<array.length;i++){

    // Some other code
    if(condition1){
        break;
    }

    // Some more code
    if(condition1){
        break;
    }

    // Some even more code
}

Тепер ви можете реально досягти цього, додавши ці умови до цього forстану?

Я думаю, що вилучення каністру breakможе бути гарною ідеєю, але не зберігати рядки коду.

Перевага написання без цього breakполягає в тому, що пост-стан циклу є очевидним і явним. Коли ви закінчите цикл і виконайте наступний рядок програми, ваша умова циклу i < array.length && !conditionповинна бути помилковою. Отже, або iбільша, або дорівнює довжині вашого масиву, або conditionце правда.

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

Це було первісною причиною, по якій Едгар Дайкстра написав "Гото вважається шкідливим". Це не було питанням стилю: виривання з циклу ускладнює формальне обґрунтування стану програми. Я написав багато break;тверджень у своєму житті, і колись, дорослий, я навіть написав goto(щоб вирватися з декількох рівнів критичної продуктивності внутрішнього циклу, а потім продовжити іншу гілку дерева пошуку). Однак я набагато більше шансів написати умовне returnтвердження з циклу (який ніколи не запускає код після циклу і тому не може вимкнути його умови), ніж a break.

Постскрипт

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

if ( array.length > 0 ) {
  // Some other code.
}
for ( int i = 1; i < array.length && !condition; i++ ) {
  // Some other code.
}

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

Я усвідомлюю, що це було не головним моментом у вашому запитанні, і ви все це просте.

Так, але ваш синтаксис нетрадиційний і, отже, поганий (tm)

Сподіваємось, ваша мова підтримує щось подібне

while(condition) //condition being a condition which if true you want to continue looping
{
    do thing; //your conditionally executed code goes here
    i++; //you can use a counter if you want to reference array items in order of index
}

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

(Особисто мені не подобається правило, що у ifвисловлюваннях завжди повинні бути дужки, що значною мірою є причиною марно витраченого вертикального простору. Зверніть увагу, що проблема витрачає вертикальний простір. Використання вертикального простору зі значущими лініями не повинно бути проблемою.)

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

for (
   int i = 0, j = 0;
   i < array.length && !condition;
   i++, j++
) {
   // stuff
}

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

array
.takeWhile(condition)  // condition can be item => bool or (item, index) => bool
.forEach(doSomething); // doSomething can be item => void or (item, index) => void

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

У цій ситуації мати стан поза циклом цілком природно. Так я починаю з

bool found = false;
size_t foundIndex;

і в циклі я напишу

if (condition) {
    found = true;
    foundIndex = i;
    break;
}

з петлею for

for (i = 0; i < something && ! found; ++i)

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

if (! found) { ... }

десь у вашій петлі.