可选参数和命名参数
不多说，上代码，自然懂
class Program { static void Main(string[] args) { var troy = new Troy(); troy.HelloWorld(1);//此时b和c都为0 troy.HelloWorld(1,2);//此时b为2，c为0，以上两个为可选参数的玩法 troy.HelloWorld(a: 1, b: 2);//命名参数玩法 troy.HelloWorld(b: 2, a: 1);//即使顺序打乱，效果也是一样 } } public class Troy { public void HelloWorld(int a, int b = 0,int c=default(int)) {//这里b和c参数就是可选参数 //注意default(int)这种玩法，表示int的默认值。 //我是第一次知道这种用法，然而非常推崇这样的玩法，因为可以有效减少你代码中的魔法数字。也许你认为0这种不算魔法数字，然而我认为能让代码更简单易懂一点点也是非常有必要的。 //就算不用魔法数字，那么default(DateTime)去判断DateTime值是否为默认值，是不是比new Datetime()更好一点呢？ } }
默认参数实际上在C#编译器编译过后就向该参数应用特性OptionalAttribute和DefaultParameterValueAttribute。并不是CLR支持的，而是C#特有的。
这两个东西看上去都那么美好，然而美好的东西并不一定真的好。
推荐用命令参数，然而不要为了调换顺序而调换顺序。实际上对VS这么强大的工具而言，命名参数只有在参数非常多的时候才有用。
如果你的参数太多，那么其实更应该考虑缩小一下参数的数量。可以考虑提取一个参数对象，传值的时候传这个参数对象就好了。
虽然我非常喜欢用默认参数，实际上它也确实很好用，特别对于重载而言，你有的时候根本没必要去写两个函数。
然而这实际上也是个坑点。
如果你和我一样喜欢用，你团队的人也喜欢用。那么最后你会发现，这个东西总是会让函数内部充满了各种各样的分支，你的参数列表也会越来越长。o(︶︿︶)o 唉
如果你不懂那么可以看一下我写的一个代码维护小故事，请想象一下你在维护的是一个业务复杂的大型系统，那么接下来的节奏会经常发生。
//最开始Troy写了一个打招呼的函数 public void 打招呼() { Console.WriteLine("你好"); //下面还有一系列握手，微笑之类的操作 } //后来老板说国际化，也要能英文打招呼.你选择了默认参数，并且为了保证以前的代码顺利运行，默认为false public void 打招呼(bool IsEnglish=false) { if (IsEnglish) { Console.WriteLine("Hello"); } else { Console.WriteLine("你好"); } //下面还有一系列握手，微笑之类的操作 } //到了上面那一步也是OK的，然而过了两天，老板跟大牛说有的老外有可能不握手，他选择拥抱。于是大牛改代码： public void 打招呼(bool IsEnglish = false, bool 是否选择拥抱 = false) { if (IsEnglish) { Console.WriteLine("Hello"); } else { Console.WriteLine("你好"); } if (是否选择拥抱) { Console.WriteLine("拥抱"); } else { Console.WriteLine("握手"); } //下面还有一系列微笑之类的操作 }
当然即使到现在，以上的代码看起来也仅仅只是分支增多而已，然而请你设身处地去想一下，如果这个系统的业务很复杂，如果后面还有需求，如果不仅仅只是一个Console.WriteLine这么简单的操作。
等到第四次去修改的时候，新来的项目组成员小菜已经没得选了。首先他不熟悉业务，不敢乱改，他甚至可能熟悉也懒得改，因为改起来已经很麻烦了（不要太相信你的队友，我就是这样的懒人(☆_☆)），那么这个时候他只能默默选择再加一个默认参数。
有第四个，肯定就会有第五个，每次想要重构感觉难度越来越大，心里越来越虚，只好随大流去加默认参数，经过大家一起努力，这段代码已经差不多10个分支了，大家都不敢改了。
如果从一开始不选择加默认参数，而是多写一个重载函数，将公共部分提炼出来，那么你觉得还会有这样的问题吗？
然而并没有什么鸟用，即使是我了解的这么清楚，我经常会觉得我在加第三次默认参数完全没有任何问题，偷点懒赶紧下班啦，代码依然能看，等我下次回来改的时候，我发现默认参数已经变成5个了。o(︶︿︶)o 唉
out和ref的故事
CLR不区分out和ref，生成的IL代码一模一样，只是元数据会有个bit值加以区分。
out表示传递的是引用类型，然而他并不需要调用的时候这个参数就初始化完毕，且要求函数执行完毕的时候out参数必须被写入过。
ref要求调用的时候这个参数就初始化完毕，且不要求函数执行完毕的时候ref参数必须被写入过。
实际上在C里面这个东西就是指针，我们这里来讲这东西传递的就是值的地址。
如果有大的值类型的传参，比如一个大型struct。
那么用这种方法传参只会传一个地址值，而不是把每个struct里面的值都压到栈中。
另外不要因为ref比out好用就不用out，out可以明确你这个参数一定会传值出来，读代码更容易。
pramas传递可变数量的参数
这个网上一大堆，我用得最多的就是String.Format方法，可以参考这个来了解。
不过要注意这个会有性能损失，因为传递的pramas一维数组，实际上是分配在堆空间中的，初始化啊，垃圾回收啊，都会有影响。
参数和返回类型的设计规范
声明方法的参数类型时，应该按照最低接口类型，更强的接口类型，基类，派生类从高到低的优先级来声明类型。
因为用接口或者基类会让你的方法更加灵活，可以选择的余地更大。
而返回类型正好相反，防止受限于特定类型。
以上是作者讲的，有道理，但是具体情况具体分析，难道要我们都去声明object，那一切都OK了？
作者的意思显然不是如此。我认为你可以在第一次的时候去选择最适合的强类型参数，但是下一次有一个类似的函数时，而两个参数间有一个共同的接口或者基类，那么是否可以考虑一下将参数的类型弱化呢？这样明显可以让代码更灵活。
但是不要因此直接就用个object之类的，不要过度设计，永远用目前最满足需求的那个，不要把未来全部考虑完全，因为你根本预测不到未来。