还有一点尚未被提及。考虑下面的代码:

    public static IEnumerable<string> GetFavoriteEmoSongs()
    {
        yield break;
    }

在调用此方法时，c#语言将返回一个空枚举数。因此，为了与语言设计(以及程序员的期望)保持一致，应该返回一个空集合。

我喜欢在这里用适当的例子来解释。

考虑一个案例。

int totalValue = MySession.ListCustomerAccounts()
                          .FindAll(ac => ac.AccountHead.AccountHeadID 
                                         == accountHead.AccountHeadID)
                          .Sum(account => account.AccountValue);

这里考虑我使用的函数..

1. ListCustomerAccounts() // User Defined
2. FindAll()              // Pre-defined Library Function

我可以很容易地使用ListCustomerAccount和FindAll代替。

int totalValue = 0; 
List<CustomerAccounts> custAccounts = ListCustomerAccounts();
if(custAccounts !=null ){
  List<CustomerAccounts> custAccountsFiltered = 
        custAccounts.FindAll(ac => ac.AccountHead.AccountHeadID 
                                   == accountHead.AccountHeadID );
   if(custAccountsFiltered != null)
      totalValue = custAccountsFiltered.Sum(account => 
                                            account.AccountValue).ToString();
}

注意:由于AccountValue不为空，Sum()函数不会为空 返回null。因此我可以直接使用它。

总是为你的客户端着想(他们正在使用你的api):

返回'null'通常会导致客户端不能正确处理null检查的问题，这会导致运行时出现NullPointerException异常。我曾经见过这样的情况，缺少空检查会导致优先级生产问题(客户端对空值使用foreach(…))。在测试期间，问题没有发生，因为所操作的数据略有不同。

Go似乎是首选nil而不是空数组的一种语言。

https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices

当声明一个空切片时，优先使用var t []string而不是t:= []string{}。前者声明一个nil切片值，而后者非nil但长度为0。它们在功能上是等价的——它们的len和cap都是0——但是nil片是首选样式。

有人可能会说，空对象模式背后的原因与支持返回空集合的原因类似。

这取决于你的合同和具体情况。 通常最好返回空集合，但有时(很少):

Null可能意味着更具体的东西; 你的API(合约)可能会强制你返回null。

一些具体的例子:

一个UI组件(来自一个不受你控制的库)，如果传递一个空集合，可能会呈现一个空表，或者如果传递null，则根本不呈现表。 在Object-to-XML (JSON/其他)中，null表示元素缺失，而空集合将呈现冗余(可能不正确)<collection /> 你正在使用或实现一个明确声明null应该返回/传递的API