Фільтрування циклів foreach за умови, коли умова проти продовжують захисні пропозиції

Я бачив, як деякі програмісти використовують це:

foreach (var item in items)
{
    if (item.Field != null)
        continue;

    if (item.State != ItemStates.Deleted)
        continue;

    // code
}

замість того, де я зазвичай використовую:

foreach (var item in items.Where(i => i.Field != null && i.State != ItemStates.Deleted))
{
    // code
}

Я навіть бачив комбінацію обох. Мені дуже подобається читати з «продовжувати», особливо при більш складних умовах. Чи є навіть різниця у продуктивності? За запитом до бази даних, я припускаю, що це буде. А як щодо звичайних списків?

Я б вважав це відповідним місцем для використання розділення команд / запитів . Наприклад:

// query
var validItems = items.Where(i => i.Field != null && i.State != ItemStates.Deleted);
// command
foreach (var item in validItems) {
    // do stuff
}

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

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

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

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

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

• Штраф за ефективність виклику делегата складає близько кількох тактових циклів, і, на щастя, ми вже давно минули дні, коли нам довелося турбуватися про окремі цикли годин.

^{Якщо з якихось причин продуктивність дійсно важлива для вас на рівні тактового циклу, використовуйте List<Item>замість цього IList<Item>, щоб компілятор міг використовувати прямі (і нездійсненні) виклики замість віртуальних викликів, і щоб ітератор List<T>, який насправді є a struct, не має бути в коробці. Але це справді дрібниці.}

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

Ви дійсно побачите переваги if(x) continue;моменту, коли вам доведеться налагоджувати цей код: Одноразовий перехід через if()s і continues прекрасно працює; одномоментний ступінь до фільтруючого делегата - це біль.