Mở rộng LINQ để chấp nhận enumerables nullable

Question

Trong khi làm việc với các phần mở rộng LINQ nó là bình thường để xem mã như thế này:

IEnumerable<int> enumerable = GetEnumerable(); 
int sum = 0; 
if (enumerable != null) 
{ 
    sum = enumerable.Sum(); 
} 

Nhằm nâng cao chất lượng mã, tôi đã viết các phương pháp khuyến nông sau đó kiểm tra các enumerables nullable và phá vỡ thực thi LINQ.

public static IEnumerable<T> IgnoreIfEmpty<T>(this IEnumerable<T> enumerable) 
{ 
    if (enumerable == null) yield break; 
    foreach (var item in enumerable) 
    { 
     yield return item; 
    } 
} 

Vì vậy, tôi có thể cấu trúc mã là như thế này:

var sum = GetEnumerable().IgnoreIfEmpty().Sum(); 

---

Câu hỏi của tôi bây giờ là:

1. gì các hình phạt có liên quan đến phương pháp khuyến nông của tôi trong thời gian chạy?
2. Có thực tiễn tốt để mở rộng LINQ theo cách đó không?

Cập nhật: khuôn khổ mục tiêu của tôi là: 3,5

Answer 1

1. Bạn sẽ có một overhead gọi phương thức, nó sẽ là không đáng kể, trừ khi bạn đang chạy nó trong một vòng lặp chặt chẽ hoặc một buổi biểu diễn kịch bản phê bình. Đó là một bóng tối so với một cái gì đó giống như một cuộc gọi cơ sở dữ liệu hoặc viết vào một hệ thống tập tin. Lưu ý rằng phương pháp này có lẽ sẽ không được gạch chân vì nó là một điều tra viên.
2. Đó là tất cả về khả năng đọc/khả năng bảo trì. Tôi mong đợi điều gì sẽ xảy ra khi tôi thấy GetEnumerable().IgnoreIfEmpty().Sum();? Trong trường hợp này, nó có ý nghĩa.

Lưu ý rằng với C# 6, chúng tôi có thể sử dụng cú pháp sau: GetEnumerable()?.Sum() trả về int?. Bạn có thể viết GetEnumerable()?.Sum() ?? 0 hoặc GetEnumerable()?.Sum().GetValueOrDefault() để lấy số nguyên không null sẽ mặc định là 0.

Nếu bạn thực sự quan tâm đến hiệu suất, bạn cũng có thể tái cấu trúc lại phương pháp của mình để nó không phải là điều tra viên. Điều này có thể làm tăng nguy cơ nội tuyến, mặc dù tôi không có ý tưởng về logic 'phức tạp' của trình biên dịch JIT:

public static IEnumerable<T> IgnoreIfEmpty<T>(this IEnumerable<T> enumerable) 
{ 
    if (enumerable == null) return Enumerable.Empty<T>(); 
    return enumerable; 
} 

Tổng quát hơn về việc gia hạn LINQ, tôi nghĩ rằng đó là hoàn toàn tốt đẹp miễn là mã có ý nghĩa . MSDN thậm chí có an article về nó. Nếu bạn nhìn vào các phương thức tiêu chuẩn Where, Select trong LINQ, và quên đi các tối ưu hóa hiệu suất mà chúng có trong đó, các phương thức chủ yếu là tất cả các phương thức một lớp.

Answer 2

Hình phạt nào được kết hợp với phương pháp tiện ích của tôi khi chạy?

Phương pháp mở rộng của bạn được chuyển thành máy trạng thái, vì vậy, chi phí tối thiểu cho điều đó, nhưng điều đó không đáng chú ý.

Có thực tiễn tốt để mở rộng LINQ theo cách đó không?

Trong câu hỏi của bạn, bạn nêu:

Trong khi làm việc với các phần mở rộng LINQ nó là bình thường để xem mã như thế này (chèn đếm được vô check here)

Và tôi cầu xin khác biệt . Thực tiễn phổ biến nói don't return null where an IEnumerable<T> is expected. Hầu hết các trường hợp phải trả về bộ sưu tập trống (hoặc IEnumerable), để lại null đến đặc biệt, vì null is not empty. Điều này sẽ làm cho phương pháp của bạn hoàn toàn thừa. Sử dụng Enumerable.Empty<T> nếu cần.

Answer 3

Bạn có thể bỏ qua phương pháp khuyến nông bổ sung và sử dụng null coalescing operator - đây là những gì nó cho, và một tấm séc một lần cho nullability nên được rất nhiều hiệu quả hơn một máy nhà nước:

IEnumerable<int> enumerable = GetEnumerable(); 
int sum = 0; 

sum = (enumerable ?? Enumerable.Empty<int>()).Sum(); 

Answer 4

Hầu hết các lần chúng tôi viết rất nhiều mã chỉ vì chúng ta đang mê hoặc bởi vẻ đẹp của sự sáng tạo của chúng tôi - không phải vì chúng tôi thực sự cần nó - và sau đó chúng tôi gọi nó là trừu tượng, tái sử dụng, khả năng mở rộng, vv ..

là mảnh liệu này ít có thể đọc được hoặc ít có thể mở rộng hoặc ít có thể sử dụng lại hoặc chậm hơn:

var sum = GetEnumerable().Where(a => a != null).Sum(); 

Bạn viết ít mã hơn - mã ít bạn kiểm tra - hãy đơn giản hơn. BTW - bạn nên viết các phương thức mở rộng nếu bạn có thể biện minh cho nó.