Foreach döngülerinin filtrelenmesi, şartların devam etmesine karşın, koruma cümleciklerine devam edilmesi.

Bazı programcıların bunu kullandığını gördüm:

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

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

    // code
}

normalde kullanacağım yer yerine:

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

İkisinin bir kombinasyonunu bile gördüm. 'Devam' ile okunabilirliği gerçekten çok seviyorum, özellikle daha karmaşık koşullarda. Performansta bile bir fark var mı? Bir veritabanı sorgusu ile olacağını tahmin ediyorum. Normal listelerden ne haber?

Bunu komut / sorgu ayırma kullanmak için uygun bir yer olarak kabul ediyorum . Örneğin:

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

Bu ayrıca, sorgu sonucuna iyi bir kendi kendine belgeleme adı vermenize olanak sağlar. Ayrıca, yeniden yapılanma fırsatlarını görmenize yardımcı olur, çünkü yalnızca verileri sorgulayan veya yalnızca mutasyona uğramış verileri kodlamayı yeniden düzenlemek, her ikisini de yapmaya çalışan karma koddan daha kolaydır.

Hata ayıklama yaparken foreach, içeriğinin validItemsbeklediğiniz çözüme göre çözülüp çözülmediğini hızlı bir şekilde kontrol etmek için daha önce kırabilirsiniz . Gerekmedikçe lambdaya girmek zorunda değilsin. Eğer lambdaya girmeniz gerekiyorsa, onu ayrı bir işleve ayırmanızı öneririm, o zaman bunun yerine ilerleyin.

Performansta bir fark var mı? Sorgu bir veritabanı tarafından destekleniyorsa, LINQ sürümünün daha hızlı çalıştırma potansiyeli vardır , çünkü SQL sorgusu daha verimli olabilir . Nesnelere LINQ ise, o zaman herhangi bir gerçek performans farkı görmezsiniz. Her zaman olduğu gibi, optimizasyonları önceden tahmin etmeyi denemek yerine kodunuzu belirleyin ve gerçekte bildirilen darboğazları düzeltin.

Tabii ki performansta bir fark var, .Where()her bir öğe için bir temsilci çağrısı yapılmasıyla sonuçlanıyor. Ancak, performans hakkında hiç endişelenmiyorum:

• Bir temsilcinin çağrılmasında kullanılan saat döngüleri, koleksiyon üzerinde yinelenen ve koşulları denetleyen kodun geri kalanının kullandığı saat döngüleriyle karşılaştırıldığında önemsizdir.

• Bir temsilciyi çağırma performansının cezası, birkaç saat döngüsünün sırasına bağlıdır ve neyse ki, bireysel saat döngüleri için endişelenmemiz gereken günleri çoktan geride bıraktık.

^{Nedense performansı ise gerçekten o zaman kullanmak, saat döngüsü düzeyinde sizin için önemli List<Item>yerine IList<Item>derleyici yerine sanal aramaların çağırır ve yineleyici böylece doğrudan (ve inlinable) yararlanabilirler böylece, List<T>aslında hangi a struct, kutulu olmak zorunda değildir. Ama bu gerçekten önemsiz şeyler.}

Bir veritabanı sorgusu farklı bir durumdur, çünkü (en azından teoride) filtrenin RDBMS'ye gönderilmesi olasılığı vardır, bu nedenle performansı büyük ölçüde iyileştirir: sadece eşleşen satırlar RDBMS'den programınıza geçişi sağlar. Ancak bunun için linq kullanmanız gerektiğini düşünüyorum, bu ifadenin olduğu gibi RDBMS'ye gönderilebileceğini sanmıyorum.

if(x) continue;Bu kodda hata ayıklamak zorunda olduğunuz anın faydalarını gerçekten göreceksiniz : Tek adım atma if()s ve continues iyi çalışıyor; filtreleme temsilcisine tek adım atmak bir acıdır.