Цикл foreach з розривом / поверненням проти циклу while з явним інваріантом та пост-умовою

Це найпопулярніший спосіб (мені здається) перевірити, чи є значення в масиві:

for (int x : array)
{
    if (x == value)
        return true;
}
return false;        

Однак у книзі, яку я багато років тому читав, напевно, Вірт або Дайкстра, було сказано, що цей стиль кращий (у порівнянні з циклом "час" з виходом всередину):

int i = 0;
while (i < array.length && array[i] != value)
    i++;
return i < array.length;

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

І все ж не можу сказати, що перша версія менш зрозуміла. Можливо, це ще зрозуміліше і простіше зрозуміти, принаймні для самих початківців. Тож я все ще задаю собі питання, який з них краще?

Можливо, хтось може дати гарне обгрунтування на користь одного з методів?

Оновлення: це не питання множини точок повернення функції, лямбда або пошуку елемента в масиві як такої. Йдеться про те, як писати петлі зі складнішими інваріантами, ніж одна нерівність.

Оновлення: Гаразд, я бачу сенс людей, які відповідають і коментують: я тут змішав цикл foreach, який сам по собі вже набагато зрозуміліший і легший для читання, ніж цикл while. Я не повинен був цього робити. Але це також цікаве питання, тому давайте залишимо його таким, яким він є: цикл foreach та додаткова умова всередині, або цикл while з явним циклом інваріантним та пост-умовою після. Здається, виграє цикл foreach з умовою та виходом / перервою. Я створять додаткове запитання без циклу foreach (для пов'язаного списку).

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

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

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

Це легко.

Майже нічого не має значення для ясності для читача. Перший варіант я знайшов неймовірно простим і зрозумілим.

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

Є ZERO DOUBT, який є кращим стилем кодування (перший набагато краще).

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

Однак у цьому конкретному випадку я можу вам сказати, чому перший алгоритм більш зрозумілий: я знаю, як виглядає і робить ітерація C ++ над синтаксисом контейнера. Я це інтерналізував. Хтось UNFAMILIAR (його новий синтаксис) із цим синтаксисом, можливо, віддасть перевагу другому варіанту.

Але як тільки ви дізнаєтесь і зрозумієте, що новий синтаксис, його основне поняття, ви можете просто використовувати. При підході до ітерації циклу (другий) ви повинні ретельно перевірити, чи користувач ПРАВИЛЬНО перевіряє, чи всі умови краю переходять на весь масив (наприклад, менше, ніж замість меншого або рівного, той же індекс, що використовується для тестування та для індексації тощо).

int i = 0;
while (i < array.length && array[i] != value)
    i++;
return i < array.length;

[…] Все більш очевидно і більш структуровано-програмування.

Не зовсім. Мінлива iіснує поза циклом , а тут і є , таким чином , частина зовнішньої області, в той час як (каламбур) xз for-loop існує тільки в межах циклу. Область застосування - це один дуже важливий спосіб впровадження структури в програмування.

Дві петлі мають різну семантику:

• Перший цикл відповідає просто на питання так / ні: "Чи містить масив об'єкт, який я шукаю?" Це робиться найкоротшим способом.

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

Оскільки відповідь на друге питання дає суворо більше інформації, ніж відповідь на перше, ви можете вибрати відповідь на друге питання, а потім отримати відповідь на перше питання. Це те, що лініяreturn i < array.length; .

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

• Використання першого варіанту петлі - чудово.
• Зміна першого варіанту просто встановити boolзмінну та перерву - теж добре. (Уникає другогоreturn твердження; відповідь доступна у змінній замість повернення функції.)
• Використання std::findпрекрасно (повторне використання коду!).
• Однак явно кодування знахідки, а потім зменшення відповіді на а boolце не.

Я запропоную взагалі третій варіант:

return array.find(value);

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

Порівняйте перетворення одного масиву в інший з циклом for:

int[] doubledArray = new int[array.length];
for (int i = 0; i < array.length; i++) {
  doubledArray[i] = array[i] * 2;
}

і за допомогою mapфункції стилю JavaScript :

array.map((value) => value * 2);

Або підсумовуючи масив:

int sum = 0;
for (int i = 0; i < array.length; i++) {
  sum += array[i];
}

проти:

array.reduce(
  (sum, nextValue) => sum + nextValue,
  0
);

Скільки часу потрібно, щоб зрозуміти, що це робить?

int[] newArray = new int[array.length];
int numValuesAdded = 0;

for (int i = 0; i < array.length; i++) {
  if (array[i] >= 0) {
    newArray[numValuesAdded] = array[i];
    numValuesAdded++;
  }
}

проти

array.filter((value) => (value >= 0));

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

Більшість сучасних мов, включаючи JavaScript , Ruby , C # та Java , використовують цей стиль функціональної взаємодії з масивами та подібними колекціями.

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

Все зводиться до того, що саме означає «краще». Для практичних програмістів це означає, що це ефективно - тобто в цьому випадку вихід безпосередньо з циклу дозволяє уникнути додаткового порівняння, а повернення булевої константи уникає дублювання порівняння; це економить цикли. Dijkstra більше займається створенням коду, який простіше довести правильність . [мені здалося, що освіта CS в Європі сприймає "доведення правильності коду" набагато серйозніше, ніж освіта CS в США, де економічні сили, як правило, домінують у практиці кодування]