本文由比特飛原創(chuàng)發(fā)布，歡迎大家踴躍轉(zhuǎn)載。
轉(zhuǎn)載請注明本文地址：https://www.byteflying.com/archives/6455。
編寫高質(zhì)量代碼的50條黃金守則-Day 01(首選隱式類型轉(zhuǎn)換)，本文由比特飛原創(chuàng)發(fā)布，轉(zhuǎn)載務(wù)必在文章開頭附帶鏈接：https://www.byteflying.com/archives/6455
該系列文章由比特飛原創(chuàng)發(fā)布，計劃用半年時間寫完全50篇文章，為大家提供編寫高質(zhì)量代碼的一般準(zhǔn)則。
1、概述
隱式類型轉(zhuǎn)換是微軟為了 C# 支持匿名類型而加入的，使用 var 通常可以使代碼的可讀性更強(qiáng)，甚至是幫我們解決一些嚴(yán)重的性能問題。為了清楚的明白 var 的作用機(jī)制，我們首先來看看編譯器為 var 做了哪些工作？
2、編譯器為var關(guān)鍵字做了什么？
首先 var 為語法糖，編譯器在編譯時根據(jù)右值推斷出表達(dá)式類型，再由編譯器將推斷出的表達(dá)式類型寫入到 IL 中，所以如下2段代碼在 IL 中完全一致。
string foo = "SomeString";
var foo = "SomeString";
編譯期間，編譯器根據(jù)右值?“SomeString”?，可以推斷出這個表達(dá)式（右值）的類型為 string 類型，于是將?var?替換為?string?，再將它寫到IL中，于是以上兩段初始化?foo?的代碼結(jié)果完全一致。
我們再來看一下兩段代碼的IL：
本文示例的源代碼
使用 DnSpy 解密的 IL
Microsoft 技術(shù)支持文檔中 ldstr 的解釋
注意：string?也是語法糖，編譯時，string?被替換為?System.String?寫進(jìn)IL。
于是我們得到了一個重要的結(jié)論：
var?為語法糖，在編譯期間就已經(jīng)被編譯器所決定，開發(fā)人員無法為編譯器決定類型。
隱式類型轉(zhuǎn)換為上述代碼帶來了良好的可讀性，任何一名開發(fā)人員都會知道第2行代碼的?var?的類型，它讓我們更加的關(guān)注代碼片段中我們所需要關(guān)注的部分，而不是把重點(diǎn)放在它的類型上。因?yàn)榇蠖鄶?shù)時候，這都是沒有意義的。
3、隱式類型轉(zhuǎn)換所帶來的良好可讀性
為了明白良好可讀性的問題，我們先來看一個代碼片段：
var foo = new SomeType();
以上代碼清晰明了，對于維護(hù)代碼的人來說，它沒有增加任何的理解成本，foo?的類型就是?SomeType?類型。很多優(yōu)秀開源項(xiàng)目中的大量被使用的工廠模式，也提供了類似的方法，如下代碼片段：
var huaWei = PhoneFactory.CreatePhone();
一個簡單的靜態(tài)工廠類 PhoneFactory ，公開了 CreatePhone 方法，閱讀這段代碼的開發(fā)人員，在幾乎沒有增加理解成本的情況下，很清楚的知道?huaWei?代表手機(jī)工廠類所生產(chǎn)的一個手機(jī)對象。但是下面的代碼，情況可能就稍有不同了：
var result = someObject.DoSomething(someParameter);
你無法輕松的知道?result?的類型和它所表達(dá)的意義，事實(shí)上，它的不良好的可讀性，表現(xiàn)在以下幾個方面：
1、在此處，result?這個變量名并不是最好的選擇；
2、someObject?的含義不明；
3、DoSomething?含糊不清；
4、無法明確的知道?someParameter?代表什么。
如果換成以下代碼，情況會好很多：
var mostPopularPhone = someObject.DoSomething(someParameter);
情況有所好轉(zhuǎn)，意思也更清楚。結(jié)合語義上下文，var?的類型不言自明。但是在這種情況下，我依然建議大家將代碼改為以下形式：
Phone mostPopularPhone = someObject.DoSomething(someParameter);
這被我寫在之前所在公司的開發(fā)手冊上，我相信我的經(jīng)驗(yàn)一定是正確的。
讓我們再來看一個新的示例：
var score = GetSomeNumber();
var rate = score / 100;
rate?的類型由變量?score?決定，然而開發(fā)者無法一眼看出?score?的類型，所以這是一個不良好的可讀性的代碼片段，我們應(yīng)該改為：
var score = GetSomeNumber();
double rate = score / 100;
怎么樣，是不是看到這樣的代碼，心里舒服多了？因?yàn)槟愕睦斫獬杀靖土?，心情舒暢了，一下子搬磚都能搬到5樓了。
于是，我們有了兩點(diǎn)總結(jié)：
1、當(dāng)含義明確，在代碼上下文較為清楚時（簡單的變量定義或工廠方法），建議優(yōu)先使用?var；
2、在其它復(fù)雜情況下，盡量直接寫出?var?的類型。
隱式類型轉(zhuǎn)換所帶來的絕非僅僅是良好的可讀性，它有時可能會幫我們消除一些難以發(fā)現(xiàn)的性能問題，這又是怎么回事呢？
4、隱式類型轉(zhuǎn)換幫我們解決嚴(yán)重的性能問題
人自以為自己是世界上最聰明的生物，事實(shí)上并非如此，有時候，編譯器比我們聰明得多，也可靠得多。
我們看看以下兩個代碼片段：
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 原先的返回類型應(yīng)當(dāng)為 IQueryable<string>，但在這里被顯式聲明的 phones 的 IEnumerable<string> 強(qiáng)制轉(zhuǎn)換了，熟悉 EF 的朋友們一定知道，IQueryable<T> 為延遲加載，本身并不會立刻查詢數(shù)據(jù)庫，事實(shí)上它只生成了一個表達(dá)式樹，在最終需要使用數(shù)據(jù)的時候才會真正執(zhí)行查詢動作。
于是 GetPhoneStartsWith1 方法將數(shù)據(jù)庫中的可能的所有數(shù)據(jù)全部取回本地，再由var result = phones.Where(r => r.StartsWith(prefix));執(zhí)行本地過濾，消耗了太多網(wǎng)絡(luò)資源，并且使用了 .Net 的數(shù)據(jù)過濾機(jī)制。
GetPhoneStartsWith2 方法則不然，phones 的類型被編譯器推斷為 IQueryable ，并不會因此執(zhí)行查詢操作，真正的查詢動作由var result = phones.Where(r => r.StartsWith(prefix));執(zhí)行，也就是說，它的數(shù)據(jù)過濾動作由數(shù)據(jù)庫引擎負(fù)責(zé)運(yùn)算，最終只將符合條件的數(shù)據(jù)發(fā)送回本地，既節(jié)省了網(wǎng)絡(luò)傳遞成本，又節(jié)省了運(yùn)算成本，豈不是一舉兩得？
5、總結(jié)
1、當(dāng)含義明確，在代碼上下文較為清楚時（簡單的變量定義或工廠方法），建議優(yōu)先使用?var；
2、在其它復(fù)雜情況下，盡量直接寫出?var?的類型；
3、盡可能地相信編譯器，大多數(shù)時候，它比我們優(yōu)秀得多。
開發(fā)人員應(yīng)牢記以上開發(fā)守則，否則，人民群眾會仇恨你，你的朋友和家人也會嘲笑你、唾棄你。
該系列文章由比特飛原創(chuàng)發(fā)布，計劃用半年時間寫完全50篇文章，為大家提供編寫高質(zhì)量代碼的一般準(zhǔn)則。
本文由?比特飛?原創(chuàng)發(fā)布，歡迎大家踴躍轉(zhuǎn)載。
轉(zhuǎn)載請注明本文地址：https://www.byteflying.com/archives/6455。
