编写高质量代码的50条黄金守则-Day 01(首选隐式类型转换)

隐式类型转换是微软为了C#支持匿名类型而加入的,使用var通常可以使代码的可读性更强,甚至是帮我们解决一些严重的性能问题。为了清楚的明白var的作用机制,我们首先来看看编译器为var做了哪些工作?

编写高质量代码的50条黄金守则-Day 01(首选隐式类型转换),本文由比特飞原创发布,转载务必在文章开头附带链接:https://www.byteflying.com/archives/6455

该系列文章由比特飞原创发布,计划用半年时间写完全50篇文章,为大家提供编写高质量代码的一般准则。

1、概述

隐式类型转换是微软为了 C# 支持匿名类型而加入的,使用 var 通常可以使代码的可读性更强,甚至是帮我们解决一些严重的性能问题。为了清楚的明白 var 的作用机制,我们首先来看看编译器为 var 做了哪些工作?

2、编译器为var关键字做了什么?

首先 var 为语法糖,编译器在编译时根据右值推断出表达式类型,再由编译器将推断出的表达式类型写入到 IL 中,所以如下2段代码在 IL 中完全一致。

string foo = "SomeString";
var foo = "SomeString";

编译期间,编译器根据右值 “SomeString” ,可以推断出这个表达式(右值)的类型为 string 类型,于是将 var 替换为 string ,再将它写到IL中,于是以上两段初始化 foo 的代码结果完全一致。

我们再来看一下两段代码的IL:

编写高质量代码的50条黄金守则-Day 01(首选隐式类型转换)
本文示例的源代码
编写高质量代码的50条黄金守则-Day 01(首选隐式类型转换)
使用 DnSpy 解密的 IL
编写高质量代码的50条黄金守则-Day 01(首选隐式类型转换)
Microsoft 技术支持文档中 ldstr 的解释

注意:string 也是语法糖,编译时,string 被替换为 System.String 写进IL。

于是我们得到了一个重要的结论:

var 为语法糖,在编译期间就已经被编译器所决定,开发人员无法为编译器决定类型。

隐式类型转换为上述代码带来了良好的可读性,任何一名开发人员都会知道第2行代码的 var 的类型,它让我们更加的关注代码片段中我们所需要关注的部分,而不是把重点放在它的类型上。因为大多数时候,这都是没有意义的。

3、隐式类型转换所带来的良好可读性

为了明白良好可读性的问题,我们先来看一个代码片段:

var foo = new SomeType();

以上代码清晰明了,对于维护代码的人来说,它没有增加任何的理解成本,foo 的类型就是 SomeType 类型。很多优秀开源项目中的大量被使用的工厂模式,也提供了类似的方法,如下代码片段:

var huaWei = PhoneFactory.CreatePhone();

一个简单的静态工厂类 PhoneFactory ,公开了 CreatePhone 方法,阅读这段代码的开发人员,在几乎没有增加理解成本的情况下,很清楚的知道 huaWei 代表手机工厂类所生产的一个手机对象。但是下面的代码,情况可能就稍有不同了:

var result = someObject.DoSomething(someParameter);

你无法轻松的知道 result 的类型和它所表达的意义,事实上,它的不良好的可读性,表现在以下几个方面:

1、在此处,result 这个变量名并不是最好的选择;

2、someObject 的含义不明;

3、DoSomething 含糊不清;

4、无法明确的知道 someParameter 代表什么。

如果换成以下代码,情况会好很多:

var mostPopularPhone = someObject.DoSomething(someParameter);

情况有所好转,意思也更清楚。结合语义上下文,var 的类型不言自明。但是在这种情况下,我依然建议大家将代码改为以下形式:

Phone mostPopularPhone = someObject.DoSomething(someParameter);

这被我写在之前所在公司的开发手册上,我相信我的经验一定是正确的。

让我们再来看一个新的示例:

var score = GetSomeNumber();
var rate = score / 100;

rate 的类型由变量 score 决定,然而开发者无法一眼看出 score 的类型,所以这是一个不良好的可读性的代码片段,我们应该改为:

var score = GetSomeNumber();
double rate = score / 100;

怎么样,是不是看到这样的代码,心里舒服多了?因为你的理解成本更低了,心情舒畅了,一下子搬砖都能搬到5楼了。

于是,我们有了两点总结:

1、当含义明确,在代码上下文较为清楚时(简单的变量定义或工厂方法),建议优先使用 var;

2、在其它复杂情况下,尽量直接写出 var 的类型。

隐式类型转换所带来的绝非仅仅是良好的可读性,它有时可能会帮我们消除一些难以发现的性能问题,这又是怎么回事呢?

4、隐式类型转换帮我们解决严重的性能问题

人自以为自己是世界上最聪明的生物,事实上并非如此,有时候,编译器比我们聪明得多,也可靠得多。

我们看看以下两个代码片段:

public IEnumerable<string> GetPhoneStartsWith1(string prefix) {
    IEnumerable<string> phones =
                    from r in db.Phones
                    select r.PhoneName;

    var result = phones.Where(r => r.StartsWith(prefix));
    return result;
}
public IEnumerable<string> GetPhoneStartsWith2(string prefix) {
    var phones =
        from r in db.Phones
        select r.PhoneName;

    var result = phones.Where(r => r.StartsWith(prefix));
    return result;
}

以上两段代码有何不同?GetPhoneStartsWith1 方法中的 phones 原先的返回类型应当为 IQueryable<string>,但在这里被显式声明的 phones 的 IEnumerable<string> 强制转换了,熟悉 EF 的朋友们一定知道,IQueryable<T> 为延迟加载,本身并不会立刻查询数据库,事实上它只生成了一个表达式树,在最终需要使用数据的时候才会真正执行查询动作。

于是 GetPhoneStartsWith1 方法将数据库中的可能的所有数据全部取回本地,再由 var result = phones.Where(r => r.StartsWith(prefix)); 执行本地过滤,消耗了太多网络资源,并且使用了 .Net 的数据过滤机制。

GetPhoneStartsWith2 方法则不然,phones 的类型被编译器推断为 IQueryable<string> ,并不会因此执行查询操作,真正的查询动作由 var result = phones.Where(r => r.StartsWith(prefix)); 执行,也就是说,它的数据过滤动作由数据库引擎负责运算,最终只将符合条件的数据发送回本地,既节省了网络传递成本,又节省了运算成本,岂不是一举两得?

5、总结

1、当含义明确,在代码上下文较为清楚时(简单的变量定义或工厂方法),建议优先使用 var;

2、在其它复杂情况下,尽量直接写出 var 的类型;

3、尽可能地相信编译器,大多数时候,它比我们优秀得多。

开发人员应牢记以上开发守则,否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你、唾弃你

该系列文章由比特飞原创发布,计划用半年时间写完全50篇文章,为大家提供编写高质量代码的一般准则。

本文由 .Net中文网 原创发布,欢迎大家踊跃转载。

转载请注明本文地址:https://www.byteflying.com/archives/6455

发表评论

登录后才能评论

评论列表(1条)