转载

Visual Studio 2015速递(1)——C#6.0新特性怎么用

对于IDE的争论这个话题，在开发部已经由来已久，甚至可以追溯到微软.NET技术发布之前，当时的主打产品是ActiveX控件，随着Borland Delphi的快速崛起，RAD势不可挡，迅速催生了很多经典的IDE，微软旗下最有名气的就是VC和VB了；此后.NET技术发布，Visual Studio迈进20XX时代，对于VS2002和VS2003我已经基本没有太深的印象了，仅仅留在记忆里的是这货要高效率，必须得安装一个叫Resharper的玩意，否则也就比记事本强那么一点点；随后微软发布了VS2005和VS2008，增加了MSBUILD引擎，优化智能提示，改进扩展模型，基本上算是成熟稳健了；之后在WPF技术上创建的VS2010一直给人臃肿华丽的印象，但是缺乏让人眼前一亮的重磅功能；最近的两次升级和发布是VS2012和VS2013，其中摆在头条的几个重大点不是性能就是Web和云。

话说微软前些日子高调的宣布Visual Studio 2015正式发布日期是7月20日，这在开发部迅速展开讨论，大抵分成三派：

技术流——我去，这IDE来来去去不就是那么些功能么，各种超级“记事本”就能搞定的事情，何必挣破头去升级，只要技术没有换代，貌似桌面还是WinForm为主，WPF半死不活；Web算是大变样，不过那是运行环境而已；另外编译还是msbuild，看起来整个意义不大。
追新流——哈哈，微软又出新版本啦，快下载来试试吧，这次肯定有不少杀手级功能，比如C#6.0，还有新的Roslyn编译平台；另外asp.net 5.0可是很有看头的，终于摘掉system.web的依赖，全线改用OWIN啦。
冷静流——让他们这批小白鼠先淌着吧，确实爽在说，反正现在的任务有不是必须要这个。

最终还是追新流声音比较大，因为大家都对C#的新版本很期待，虽然微软C#语言组的PM Mads Torgersen说过，“C# 6.0主要是增强和提升效率”，但是对于控件开发小组而言依然相当期待，因为代码的可读性和效率是我们非常关键的部分。

这里让我们一起再来简单回顾一下C#6.0的重要特性吧：

NameOf表达式。曾几何时，我们一直在hardcode各种参数异常，譬如：
void ThrowArgumentNullException(string firstVersionArgumentName)
{
threw new ArgumentNullException(“firstVersionArgumentName”, “can not be null”);
}
很悲催的是第二版说不定PM就说：“这个参数名字不合适，咱改改吧”，得益于IDE的重构功能，这个很容易，直接F2改名然后回车，签入代码；若干天后，测试找上门来，说你的参数名字是变了，但是异常信息没变。好吧，原来这里的hardcode字符组，这个是不会随着重构功能改变的！
再来看看新的Nameof表达式给我带来什么，同样的功能，代码如下：
void ThrowArgumentNullException(string firstVersionArgumentName)
{
threw new ArgumentNullException(nameof(firstVersionArgumentName), “can not be null”);
}
在回到IDE中，再次按F2触发重构改名，你会发现异常信息也能一起改变了。
空值判断操作符（Null-conditional operators），又一个重量级代码提升，直接上示例代码：
public static string Tuncate(this string value, int length)
{
if(!string.IsNullOrEmpty(value))
{
return value.Substring(0, Math.Min(value.Length, length));
}
return value;
}
这只是一个很小的折影，在开发过程中我们有无数这样的方法，无数次重复为空判断，但是这对代码的可读性和业务处理没有任何提升，反而增加了代码复杂度，让我们更难理解当初的设计初衷。显然，C#6.0使用null-conditional operators来向前推进了一大步：
public static string Tuncate(this string value, int length)
{
return value?.Substring(0, Math.Min(value.Length, length));
}
是不是更加简洁明了，而且能突出业务核心逻辑！
字符串嵌入值（string interpolation），终于可以摆脱长长的string.Format函数了，如下代码就可以轻松改写了：
var fullName = string.Format(“FirstName is {0}, LastName is {1}”, customer.FirstName, customer.LastName);
使用新特性之后代码：
var fullName = “FirstName is /{customer.FirstName}, LastName is /{customer.LastName}”;
Lambda表达式函数和仅get的属性。对于那些只有一两句话的函数，可以省掉一些废话了，这个新功能可以大大节省人力：
public override string ToString() => “/{FirstName} /{LastName}”;
public override int GetHashcode() => (FirstName.GetHashcode()^8) & (LastName.GetHashcode());
public DateTime TimeStamp { get; } => DateTime.UtcNow;
自动属性（auto-property）和索引初始化（Index initializers），终于可以像变量一样给属性赋初值了，大大提升代码可读性。
public string FirstName { get; set; } = “John”;
public string LastName { get; set; } = “Lennon”;
private Dictionary<int, string> _dicts = new Dictionary<int, string> { [3] = “third”, [8] = “eight” };
public string FullName { get; }
pubic MyClass ()
{
FullName = “/{FirstName} /{LastName}”;
}
异常过滤器（Exception filter），回想曾经的错误处理，为了提示不同的错误，我们不得不定义多个自定义异常，有了异常过滤器之后，我们可以通过给异常添加一个简单的额外属性就可以解决了：
try { … }
catach ( CustomException ex ) if ( CheckException(ex) )
{ … }
想想这个还有一个好处，比如严重异常日志，在这个过滤器里我们可以最简单的判断，发现若果是严重的问题，可以直接做更早的提醒。
引用静态类（using static），懒人必备，想想某大仙在前面定义了一个超级无敌的静态类和辅助方法，你有超级多的地方需要用，然后你就得一遍一遍的敲这个静态类名和方法名，万一这个静态类名字很长就更悲催了，拷贝吧，最后总是看着大段大段重复心里很不爽（程序员大部分都有代码洁癖），好吧，这个应用静态类就能很好的解决了：
using GrapeCity.Demo.LongLongNameStaticClass;
void AnotherMethod()
{
UtilA(…) // no LongLongNameStaticClass.UtilA(…)
}
Await增强，终于可以把await放到catch和finally块中了，典型的用例是像IO资源操作之类可以简单整洁的处理关闭了：
Resource res = null;
try
{
res = await Resource.OpenAsync(…); //一直都可以而且一直这么做的
...
}
catch(ResourceException ex)
{
await Resource.LogAsync(res, ex); //写日志吧，不阻塞
}
finally
{
res?.CloseAsync(); //结合空值判断操作符更简洁明了
}