Lọc các vòng lặp foreach với điều kiện nơi vs tiếp tục các mệnh đề bảo vệ

Tôi đã thấy một số lập trình viên sử dụng điều này:

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

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

    // code
}

thay vì nơi tôi thường sử dụng:

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

Tôi thậm chí đã nhìn thấy một sự kết hợp của cả hai. Tôi thực sự thích khả năng đọc với 'tiếp tục', đặc biệt với các điều kiện phức tạp hơn. Thậm chí có một sự khác biệt trong hiệu suất? Với một truy vấn cơ sở dữ liệu tôi giả sử sẽ có. Những gì về danh sách thường xuyên?

Tôi sẽ coi đây là một nơi thích hợp để sử dụng phân tách lệnh / truy vấn . Ví dụ:

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

Điều này cũng cho phép bạn đưa ra một tên tự viết tài liệu tốt cho kết quả truy vấn. Nó cũng giúp bạn nhìn thấy các cơ hội để tái cấu trúc, bởi vì việc tái cấu trúc mã dễ dàng hơn nhiều khi chỉ truy vấn dữ liệu hoặc chỉ làm thay đổi dữ liệu so với mã hỗn hợp cố gắng thực hiện cả hai.

Khi gỡ lỗi, bạn có thể ngắt trước foreachđể nhanh chóng kiểm tra xem nội dung validItemsgiải quyết theo những gì bạn mong đợi. Bạn không cần phải bước vào lambda trừ khi bạn cần. Nếu bạn cần phải bước vào lambda, thì tôi khuyên bạn nên đưa nó vào một chức năng riêng biệt, sau đó bước qua đó.

Có sự khác biệt trong hiệu suất? Nếu truy vấn được hỗ trợ bởi cơ sở dữ liệu, thì phiên bản LINQ có khả năng chạy nhanh hơn, vì truy vấn SQL có thể hiệu quả hơn. Nếu đó là LINQ to Object, thì bạn sẽ không thấy bất kỳ sự khác biệt hiệu suất thực sự nào. Như mọi khi, hồ sơ mã của bạn và sửa chữa các nút thắt thực sự được báo cáo, thay vì cố gắng dự đoán trước sự tối ưu hóa.

Tất nhiên, có một sự khác biệt về hiệu suất, .Where()kết quả là một cuộc gọi đại biểu được thực hiện cho mỗi mục duy nhất. Tuy nhiên, tôi sẽ không lo lắng về hiệu suất:

• Các chu kỳ đồng hồ được sử dụng trong việc gọi một đại biểu là không đáng kể so với các chu kỳ đồng hồ được sử dụng bởi phần còn lại của mã lặp lại trong bộ sưu tập và kiểm tra các điều kiện.

• Hình phạt về hiệu suất của việc triệu tập một đại biểu là theo thứ tự của một vài chu kỳ đồng hồ, và may mắn thay, chúng ta đã qua những ngày mà chúng ta phải lo lắng về các chu kỳ đồng hồ riêng lẻ.

^{Nếu vì một lý do nào đó, hiệu suất thực sự quan trọng đối với bạn ở cấp độ chu kỳ đồng hồ, thì hãy sử dụng List<Item>thay vì IList<Item>, để trình biên dịch có thể sử dụng các cuộc gọi trực tiếp (và không thể thực hiện được) thay vì các cuộc gọi ảo và List<T>thực sự là trình lặp của a struct, không phải đóng hộp. Nhưng đó thực sự là những thứ tầm thường.}

Một truy vấn cơ sở dữ liệu là một tình huống khác nhau, vì (ít nhất là về lý thuyết) có khả năng gửi bộ lọc đến RDBMS, do đó cải thiện hiệu năng rất nhiều: chỉ các hàng khớp sẽ thực hiện chuyến đi từ RDBMS đến chương trình của bạn. Nhưng vì điều đó tôi nghĩ rằng bạn sẽ phải sử dụng linq, tôi không nghĩ biểu thức này có thể được gửi đến RDBMS như vậy.

Bạn sẽ thực sự thấy được lợi ích của if(x) continue;thời điểm bạn phải gỡ lỗi mã này: Bước đơn trên if()s và continues hoạt động độc đáo; bước đơn vào đại biểu lọc là một nỗi đau.