Чи слід перемістити нетривіальні умовні оператори до розділу ініціалізації циклів?

Я отримав цю ідею з цього питання на stackoverflow.com

Наступна закономірність є загальною:

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

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

Чи краще це оголосити в розділі ініціалізації циклу як такого?

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

Це більш зрозуміло?

Що робити, якщо умовний вираз такий простий, як

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

Що я б робив, це щось подібне:

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

Чесно кажучи, єдиною вагомою причиною забивати ініціалізацію j(зараз limit) у заголовку циклу є правильність її розміщення. Все, що потрібно для того, щоб невдача була приємною тісною сферою.

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

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

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

Однак ...

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

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

Як сказав у своїй відповіді @Karl Bielefeldt, це, як правило, не питання.

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

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

Тепер умовною умовою кожної ітерації є саме те, >= 0що кожен компілятор складе в 1 або 2 інструкції по збірці. Кожен процесор, зроблений за останні кілька десятиліть, повинен мати такі базові перевірки; роблячи швидку перевірку на моїй машині x64, я бачу, що це передбачувано перетворюється на cmpl $0x0, -0x14(%rbp)(значення long-int-зіставлення 0 порівняно з зареєстрованим rbp зміщено -14) і jl 0x100000f59(перейти до інструкції, що слідує за циклом, якщо попереднє порівняння було вірним для "2nd-arg <1-й арг. ») .

Зауважте, що я видалив + 1з Math.floor(Math.sqrt(x)) + 1; для того, щоб математика спрацювала, початкове значення повинно бути int i = «iterationCount» - 1. Також варто зазначити, що ваш ітератор повинен бути підписаний; unsigned intне працюватиме і, ймовірно, компілятор попереджає.

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

Це стає цікавим, як тільки Math.sqrt (x) буде замінено Mymodule.SomeNonPureMethodWithSideEffects (x).

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

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

На мою думку, це дуже специфічно для мови. Наприклад, якщо використовувати C ++ 11, я б підозрював, що якщо перевірка стану була constexprфункцією, компілятор дуже імовірно оптимізуватиме декілька виконань, оскільки знає, що кожного разу буде отримувати те саме значення.

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

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

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