应遵循《.NET设计规范：.NET约定惯用法与模式》一书。和十年前第一版出版时一样，书中给出的原则在当前依然有指导意义。
API设计是最重要的。设计不好的API会在极大地增加软件缺陷，同时降低可重用性。
时刻牢记“良性循环”（Pit of Success）这一哲理：让正确的事情更易于做，让犯错误更加困难。
移除“线路噪音”（Line Noise）和“样板”（Boilerplate）代码，聚焦于对业务逻辑的关注。
出于性能考虑而牺牲代码清晰度前，请认真考虑一下。
C# 7是一个重大更新，其中提供了很多有意思的新功能。虽然已有大量的文章介绍这些功能可以做什么，但是鲜有文章介绍应如何使用这些功能。本文将过一遍《.NET设计规范：.NET约定惯用法与模式》（译者注：英文书名为“Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries”）一书中给出的指导原则，力图更好地使用C# 7的新特性。
元组返回（Tuple Returns）通常在C#编程中，一个函数返回多个值实现起来十分繁琐。一种做法是使用输出参数，这只适用于暴露异步方法的情况。另一种做法是使用Tuple<T>。创建Tuple<T>过于啰嗦，需要做内存分配，并且Tuple的字段没有描述性名字。也可以使用自定义的结构体。虽然结构体在性能上要优于元组，但是大量使用一次性类型会将代码弄得一团糟。而使用具有动态特性的匿名类型，存在性能不好的问题，还缺少静态类型检查。
在C# 7中新提供了元组返回语法，它解决了全部上述问题。下面给出一个基本语法的例子：
public (string, string) LookupName(long id) // tuple return type { return ("John", "Doe"); //元组常值。 } var names = LookupName(0); var firstName = names.Item1; var lastName = names.Item2;该函数的实际返回类型是ValueTuple<string, string>。正如名称所示，ValueTuple<string, string>类似于Tuple<T>类，是一个轻量级的结构体。它解决了类型膨胀（Type Bloat）问题，但是依然没有解决描述性名称这一困扰Tuple<T>的问题。我们看一下如下的例子：
public (string First, string Last) LookupName(long id) var names = LookupName(0); var firstName = names.First; var lastName = names.Last;其中的返回类型依然是ValueTuple<string, string>，但是现在编译器在函数中添加了一个TupleElementNames属性。这样调用该函数的代码就可以使用描述性名称，而不再是Item1或Item2这样的名称了。
警告： TupleElementNames属性只能由编译器赋予。如果返回类型上使用了反射，你将只能看到裸的ValueTuple<T>结构体。因为在获得结果时，属性是位于函数本身上，而这个信息丢失了。
编译器会尽可能维护额外类型的幻象。例如，给出如下这些声明：
var a = LookupName(0); (string First, string Last) b = LookupName(0); ValueTuple<string, string> c = LookupName(0); (string make, string model) d = LookupName(0);在编译器看来，a和b同是(string First, string Last)。鉴于c被显式声明为ValueTuple<string, string>，因此不存在c.First属性。
该例中d的赋值语句展示了这一设计的失灵之处，即会在一定程度上导致缺失类型安全。字段意外地重命名是一个非常容易发生的问题，一个元组可以错误地指定给另一个恰好具有同样形状的元组。这同样是由于编译器没有真正地将(string First, string Last)和(string make, string model)区分为不同的类型。
ValueTuple是可变的有意思的是， ValueTuple是可变的。Mads Torgersen给出了这样的解释：
为什么通常可变结构体是不好的，不要应用于元组？下面给出原因。
如果你按正常的封装方式编写了一个可变结构体，并且其中具有私有的状态，还有公开的修改器（Mutator）属性和方法，那么你可能就会陷入一些严重的错误中。因为只要结构体是保持在只读变量中，那么修改器就会默默地工作于结构体的一个拷贝上！
但是元组的确有公开的可变字段。它在设计上并未考虑修改器，因此不存在出现上述现象的风险。
此外，ValueTuple是结构体，而结构体在传递时需要进行拷贝。结构体并不直接在线程间共享，也不承担“共享可变状态”的风险。这不同于System.Tuple家族的类型，这些类型也是类。为确保线程安全，需要这些类型是不可变的。
注意，这里Torgersen所指的是“字段”，而不是“属性”。对于使用元组返回函数结果的反射库，这会导致问题。
元组返回的指导原则当字段列表规模较小并不会发生更改时，考虑使用元组返回，而不是out参数。
对元组返回中的描述性名字使用帕斯卡拼写法（PascalCase），这会使得元组字段看上去就像是正常的类和结构中的属性。
在不进行解析就读取元组返回时，使用var，以避免意外地误标字段。
X 如果想要对返回值使用反射，应避免返回值元组。
X 如果在未来的版本中可能会返回额外的字段，那么就不要在公开API上使用元组返回。在元组返回中添加字段是一种破坏性变更。
析构多值返回