【轉】Effective C#觀後感之提高Unity中C#代碼品質的21條準則

標籤：比較   物件導向   cond   簡化   必看   成員變數   尋找   快捷   有關   

轉自：http://blog.csdn.net/swj524152416/article/details/75418162我們知道，在C++領域，作為進階閱讀材料，必看的書是《Effective C++》。 而《Effective C#》之於C# ，是類似《Effective C++》之於C++一樣的存在。

這篇文章，將《Effective C# Second Edition》一書中適用於Unity遊戲引擎裡使用C#的經驗之談進行了提煉，總結成為21條（一開始總結的是22條，後來發現第22條也是.NET的特性，Unity版本的mono並沒有實現，所以嚴格意義上來說是21條）準則，供各位快速地掌握這本書的知識梗概，在Unity中寫出更高品質的C#代碼。

 

《Effective C# Second Edition》一書原本有50條原則，但這50條原則是針對C#語言本身以及.NET來寫的，我在閱讀過程中，發現是有些原則並不適用於Unity中mono版本的C#的使用。於是，在進行讀書筆記總結的時候，將不適用的原則略去，同時將適用的原則進行提煉，總結出21條，構成本文的內容。

 

需要注意，因為是挑出了書中適用的準則，導致準則序號有些跳躍，為了閱讀方便，本文對這些序號進行了重新排列。重排後，標題中與書中序號不一樣的準則，都在該原則總結的末章節附註明了對應的原書序號。

 

同樣地，作為總結式文章，每一條的內容都高度概括，也許理解坡度比較陡，若有讀到不太理解的地方，建議大家去閱讀原書，英文版和中文版均可，看看原書中提供的各種代碼與樣本，這樣掌握起來就會事半功倍。

 

本文內容思維導圖式總結

以下是本文內容，提高Unity中C#代碼品質的22條準則的總結式思維導圖：

 

原則1

儘可能地使用屬性而不是可直接存取的資料成員

       

● 屬性(property)一直是C#語言中比較有特點的存在。屬性允許將資料成員作為共有介面的一部分暴露出去，同時仍舊提供物件導向環境下所需的封裝。屬性這個語言元素可以讓你像訪問資料成員一樣使用，但其底層依舊是使用方法實現的。

 

● 使用屬性，可以非常輕鬆的在get和set程式碼片段中加入檢查機制。

 

需要注意，正因為屬性是用方法實現的，所以它擁有方法所擁有的一切語言特性：

1）屬性增加多線程的支援是非常方便的。你可以加強 get 和 set 訪問器（accessors）的實現來提供資料訪問的同步。

2）屬性可以被定義為virtual。

3）可以把屬性擴充為abstract。

4）可以使用泛型版本的屬性類型。

5）屬性也可以定義為介面。

6）因為實現實現訪問的方法get與set是獨立的兩個方法，在C# 2.0之後，你可以給它們定義不同的存取權限，來更好的控制類成員的可見度。

7）而為了和多維陣列保持一致，我們可以建立多維索引器，在不同的維度上使用相同或不同類型。

 

無論何時，需要在類型的公有或保護介面中暴露資料，都應該使用屬性。如果可以也應該使用索引器來暴露序列或字典。現在多投入一點時間使用屬性，換來的是今後維護時的更加遊刃有餘。

 

原則2

偏向於使用運行時常量而不是編譯時間常量

       

對於常量，C#裡有兩個不同的版本：運行時常量（readonly）和編譯時間常量（const）。

 

應該盡量使用運行時常量，而不是編譯器常量。雖然編譯器常量略快，但並沒有運行時常量那麼靈活。應僅僅在那些效能異常敏感，且常量的值在各個版本之間絕對不會變化時，再使用編譯時間常量。

 

編譯時間常量與運行時常量不同之處表現在於他們的訪問方式不同，因為Readonly值是運行時解析的：

● 編譯時間常量（const）的值會被目標代碼中的值直接取代。

● 運行時常量（readonly）的值是在運行時進行求值。● 引用運行時產生的IL將引用到readonly變數，而不是變數的值。

 

這個差別就帶來了如下規則：

● 編譯時間常量（const）僅能用於數值和字串。

● 運行時常量（readonly）可以為任意類型。運行時常量必須在建構函式或初始化器中初始化，因為在建構函式執行後不能再被修改。你可以讓某個readonly值為一個DataTime結構，而不能指定某個const為DataTIme。

● 可以用readonly值儲存執行個體常量，為類的每個執行個體存放不同的值。而編譯時間常量就是靜態常量。

● 有時候你需要讓某個值在編譯時間才確定，就最好是使用運行時常量（readonly）。

● 標記版本號碼的值就應該使用運行時常量，因為它的值會隨著每個不同版本的發布而改變。

● const優於readonly的地方僅僅是效能，使用已知的常量值要比訪問readonly值略高一點，不過這其中的效率提升，可以說是微乎其微的。

 

綜上，在編譯器必須得到確定數值時，一定要使用const。例如特性（attribute）的參數和枚舉的定義，還有那些在各個版本發布之間不會變化的值。除此之外的所有情況，都應盡量選擇更加靈活的readonly常量。

 

原則3

推薦使用is 或as操作符而不是強制類型轉換

            

● C#中，is和as操作符的用法概括如下：

is : 檢查一個對象是否相容於其他指定的類型,並返回一個Bool值,永遠不會拋出異常。

as：作用與強制類型轉換是一樣,但是永遠不會拋出異常,即如果轉換不成功,會返回null。

 

● 儘可能的使用as操作符，因為相對於強制類型轉換來說，as更加安全，也更加高效。

 

● as在轉換失敗時會返回null，在轉換對象是null時也會返回null，所以使用as進行轉換時，只需檢查返回的引用是否為null即可。

 

● as和is操作符都不會執行任何使用者自訂的轉換，它們僅當運行時類型符合目標類型時才能轉換成功，也不會在轉換時建立新的對象。

 

● as運算子對實值型別是無效，此時可以使用is，配合強制類型轉換進行轉換。

 

● 僅當不能使用as進行轉換時，才應該使用is操作符。否則is就是多餘的。

 

原則4

 推薦使用條件屬性而不是#if條件編譯

            

● 由於#if/#endif很容易被濫用，使得編寫的代碼難於理解且更難於調試。C#為此提供了一條件特性(Conditional attribute)。使用條件特性可以將函數拆分出來，讓其只有在定義了某些環境變數或設定了某個值之後才能編譯並成為類的一部分。Conditional特性最常用的地方就是將一段代碼變成調試語句。

 

● Conditional特性只可應用在整個方法上，另外，任何一個使用Conditional特性的方法都只能返回void類型。不能再方法內的代碼塊上應用Conditional特性。也不可以在有傳回值的方法上應用Conditional特性。但應用了Conditional特性的方法可以接受任意數目的參考型別參數。

 

● 使用Conditional特性產生的IL要比使用#if/#Eendif時更有效率。同時，將其限制在函數層面上可以更加清晰地將條件性的代碼分離出來，以便進一步保證代碼的良好結構。

 

原則5

理解幾個等同性判斷之間的關係

● C#中可以建立兩種類型：實值型別和參考型別。如果兩個參考型別的變數指向的是同一個對象，它們將被認為是“引用相等”。如果兩個實值型別的變數類型相同，而且包含同樣的內容，它們被認為是“值相等”。這也是等同性判斷需要如此多方法的原因。

 

● 當我們建立自己的類型時（無論是類還是struct），應為類型定義“等同性”的含義。C#提供了4種不同的函數來判斷兩個對象是否“相等”。

1）public static bool ReferenceEquals (object left, object right);判斷兩個不同變數的對象標識（object identity）是否相等。無論比較的是參考型別還是實值型別，該方法判斷的依據都是對象標識，而不是對象內容。

2）public static bool Equals (object left, object right); 用於判斷兩個變數的運行時類型是否相等。

3）public virtual bool Equals(object right); 用於重載

4）public static bool operator ==(MyClass left, MyClass right); 用於重載

 

● 不應該覆寫Object.referenceEquals（）靜態方法和Object.Equals（）靜態方法，因為它們已經完美的完成了所需要完成的工作，提供了正確的判斷，並且該判斷與運行時的具體類型無關。對於實值型別，我們應該總是覆寫Object.Equals（）執行個體方法和operatior==( ),以便為其提供效率更高的等同性判斷。對於參考型別，僅當你認為相等的含義並非是對象標識相等時，才需要覆寫Object.Equals( )執行個體方法。在覆寫Equals( )時也要實現IEquatable<T>。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則6。

 

原則6

瞭解GetHashCode( )的一些坑

● GetHashCode( )方法在使用時會有不少坑，要謹慎使用。GetHashCode()函數僅會在一個地方用到，即為基於散列(hash)的集合定義鍵的散列值時，此類集合包括HashSet<T>和Dictionary<K,V>容器等。對參考型別來講，索然可以正常工作，但是效率很低。對實值型別來講，基類中的實現有時甚至不正確。而且，編寫的自己GetHashCode( )也不可能既有效率又正確。

 

● 在.NET中，每個對象都有一個散列碼，其值由System.Object.GetHashCode()決定。

 

● 實現自己的GetHashCode( )時，要遵循上述三條原則：

1）如果兩個對象相等（由operation==定義），那麼他們必鬚生成相同的散列碼。否則，這樣的散列碼將無法用來尋找容器中的對象。

2）對於任何一個對象A，A.GetHashCode()必須保持不變。

3）對於所有的輸入，散列函數應該在所有整數中按隨機分別產生散列碼。這樣散列容器才能得到足夠的效率提升。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則7。

 

原則7

理解短小方法的優勢

將C#代碼翻譯成可執行檔機器碼需要兩個步驟。

C#編譯器將產生IL，並放在程式集中。隨後，JIT將根據需要逐一為方法（或是一組方法，如果涉及內聯）產生機器碼。短小的方法讓JIT編譯器能夠更好地平攤編譯的代價。短小的方法也更適合內聯。

 

除了短小之外，簡化控制流程程也很重要。控制分支越少，JIT編譯器也會越容易地找到最適合放在寄存器中的變數。

 

所以，短小方法的優勢，並不僅體現在代碼的可讀性上，還關係到程式運行時的效率。

 

PS:此原則對應於《EffectiveC# Second Edition》中原則11。

 

原則8

選擇變數初始化而不是指派陳述式

成員初始化器是保證類型中成員均被初始化的最簡單的方法——無論調用的是哪一個建構函式。初始化器將在所有建構函式執行之前執行。使用這種文法也就保證了你不會再添加的新的建構函式時遺漏掉重要的初始化代碼。

 

綜上，若是所有的建構函式都要將某個成員變數初始化成同一個值，那麼應該使用初始化器。

 

PS: 此原則對應於《Effective C# Second Edition》中原則12。

 

原則9

正確地初始化靜態成員變數

● C#提供了有靜態初始化器和靜態建構函式來專門用於靜態成員變數的初始化。

 

● 靜態建構函式是一個特殊的函數，將在其他所有方法執行之前以及變數或屬性被第一次訪問之前執行。可以用這個函數來初始化靜態變數，實現單例模式或執行類可用之前必須進行的任何操作。

 

● 和執行個體初始化一樣，也可以使用初始化器文法來替代靜態建構函式。若只是需要為某個靜態成員分配空間，那麼不妨使用初始化器的文法。而若是要更複雜一些的邏輯來初始化靜態成員變數，那麼可以使用靜態建構函式。

 

● 使用靜態建構函式而不是靜態初始化器最常見的理由就是處理異常。在使用靜態初始化器時，我們無法自己捕獲異常。而在靜態建構函式中卻可以做到。

 

PS: 此原則對應於《Effective C# Second Edition》中原則13。

 

原則10

使用建構函式鏈（減少重複的初始化邏輯）

      

● 編寫建構函式很多時候是個重複性的勞動，如果你發現多個建構函式包含相同的邏輯，可以將這個邏輯提取到一個通用的建構函式中。這樣既可以避免代碼重複，也可以利用建構函式初始化器來產生更高效的目標代碼。

 

● C#編譯器將把建構函式初始化器看做是一種特殊的文法，並移除掉重複的變數初始化器以及重複的基類建構函式調用。這樣使得最終的對象可以執行最少的代碼來保證初始化的正確性。

 

● 建構函式初始化器允許一個建構函式去調用另一個建構函式。而C# 4.0添加了對預設參數的支援，這個功能也可以用來減少建構函式中的重複代碼。你可以將某個類的所有建構函式統一成一個，並為所有的選擇性參數指定預設值。其他的幾個建構函式調用某個建構函式，並提供不同的參數即可。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則14。

 

原則11

實現標準的銷毀模式

● GC可以高效地管理應用程式使用的記憶體。不過建立和銷毀堆上的對象仍舊需要時間。若是在某個方法中建立了太多的引用對象，將會對程式的效能產生嚴重的影響。

 

這裡有一些規則，可以幫你盡量降低GC的工作量：

1）若某個參考型別（實值型別無所謂）的局部變數用於被頻繁調用的常式中，那麼應該將其提升為成員變數。

2）為常用的類型執行個體提供靜態對象。

3）建立不可變類型的最終值。比如string類的+=操作符會建立一個新的字串對象並返回，多次使用會產生大量垃圾，不推薦使用。對於簡單的字串操作，推薦使用string.Format。對於複雜的字串操作，推薦使用StringBuilder類。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則16。

 

原則12

區分實值型別和參考型別

● C#中，class對應參考型別，struct對應實值型別。

 

● C#不是C++，不能將所有類型定義成實值型別並在需要時對其建立引用。C#也不是Java，不像Java中那樣所有的東西都是參考型別。你必須在建立時就決定類型的表現行為，這相當重要，因為稍後的更改可能帶來很多災難性的問題。

 

● 實值型別無法實現多態，因此其最佳用途就是存放資料。參考型別支援多態，因此用來定義應用程式的行為。

 

●  一般情況下，我們習慣用class，隨意建立的大都是參考型別，若下面幾點都肯定，那麼應該建立struct實值型別：

1）該類型主要職責在於資料存放區嗎？

2）該類型的公有介面都是由訪問其資料成員的屬性定義的嗎？

3）你確定該類型絕不會有衍生類別型嗎？

4）你確定該類型永遠都不需要多態支援嗎？

 

● 用實值型別表示底層儲存資料的類型，用參考型別來封裝程式的行為。這樣，你可以保證類暴露出的資料能以複製的形式安全提供，也能得到基於棧儲存和使用內聯方式儲存帶來的記憶體效能提升，更可以使用標準的物件導向技術來表達應用程式的邏輯。而倘若你對類型未來的用圖不確定，那麼應該選擇參考型別。

 

PS: 此原則對應於《Effective C# Second Edition》中原則18。

 

原則13

保證0為實值型別的有效狀態

在建立自訂枚舉值時，請確保0是一個有效選項。若你定義的是標誌(flag)，那麼可以將0定義為沒有選中任何狀態的標誌（比如None）。即作為標記使用的枚舉值（即添加了Flags特性）應該總是將None設定為0。

 

PS: 此原則對應於《Effective C# Second Edition》中原則19。

 

原則14

保證實值型別的常量性和原子性

常量性的類型使得我們的代碼更加易於維護。不要盲目地為類型中的每一個屬性都建立get和set訪問器。對於那些目的是儲存資料的類型，應該儘可能地保證其常量性和原子性。

 

PS: 此原則對應於《Effective C# Second Edition》中原則20。

 

原則15

限制類型的可見度

在保證類型可以完成其工作的前提下。你應該儘可能地給類型分配最小的可見度。也就是，僅僅暴露那些需要暴露的。盡量使用較低可見度的類來實現公有介面。可見度越低，能訪問你功能的代碼越少，以後可能出現的修改也就越少。

 

PS: 此原則對應於《Effective C# Second Edition》中原則21。

 

原則16

通過定義並實現介面替代繼承

● 理解抽象基類（abstract class）和介面（interface）的區別：

1）介面是一種契約式的設計方式，一個實現某個介面的類型，必須實現介面中約定的方法。抽象基類則為一組相關的類型提供了一個共同的抽象。也就是說抽象基類描述了對象是什麼，而介面描述了對象將如何表現其行為。

 

2）介面不能包含實現，也不能包含任何具體的資料成員。而抽象基類可以為衍生類別提供一些具體的實現。

 

3）基類描述並實現了一組相互關聯類型間共用的行為。介面則定義了一組具有原子性的功能，供其他不相關的具體類型來實現。

 

● 理解好兩者之間的差別，我們便可以創造更富表現力、更能應對變化的設計。使用類層次來定義相關的類型。用介面暴露功能，並讓不同的類型實現這些介面。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則22。

 

原則17

理解介面方法和虛方法的區別

第一眼看來，實現介面和覆寫虛方法似乎沒有什麼區別，實際上，實現介面和覆寫虛方法之間的差別很大。

1）介面中聲明的成員方法預設情況下並非虛方法，所以，衍生類別不能覆寫基類中實現的非虛介面成員。若要覆寫的話，將介面方法聲明為virtual即可。

 

2）基類可以為介面中的方法提供預設的實現，隨後，衍生類別也可以聲明其實現了該介面，並從基類中繼承該實現。

 

3）實現介面擁有的選擇要比建立和覆寫虛方法多。我們可以為類層次建立密封（sealed）的實現，虛實現或者抽象的契約。還可以建立密封的實現，並在實現介面的方法中提供虛方法進行調用。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則23。

 

原則18

用委託實現回調

在C#中，回調是用委託來實現的，主要要點如下：

1）委託為我們提供了型別安全的回調定義。雖然大多數常見的委託應用都和事件有關，但這並不是C#委託應用的全部場合。當類之間有通訊的需要，並且我們期望一種比介面所提供的更為鬆散的耦合機制時，委託便是最佳的選擇。

 

2）委託允許我們在運行時配置目標並通知多個客戶對象。委派物件中包含一個方法的應用，該方法可以是靜態方法，也可以是執行個體方法。也就是說，使用委託，我們可以和一個或多個在運行時聯絡起來的客戶對象進行通訊。

 

3）由於回調和委託在C#中非常常用，以至於C#特地以lambda運算式的形式為其提供了精簡文法。

 

4）由於一些曆史原因，.NET中的委託都是多播委託（multicast delegate）。多播委託調用過程中，每個目標會被依次調用。委派物件本身不會捕捉任何異常。因此，任何目標拋出的異常都會結束委託鏈的調用。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則24。

 

原則19

用事件模式實現通知

● 事件提供了一種標準的機制來通知監聽者，而C#中的事件其實就是觀察者模式的一個文法上的快捷實現。

 

● 事件是一種內建的委託，用來為事件處理函數提供型別安全的方法簽名。任意數量的客戶對象都可以將自己的處理函數註冊到事件上，然後處理這些事件，這些客戶對象無需在編譯器就給出，事件也不必非要有訂閱者才能正常工作。

 

● 在C#中使用事件可以降低寄件者和可能的通知接受者之間的耦合，寄件者可以完全獨立於接受者進行開發。

 

PS: 此原則對應於《EffectiveC# Second Edition》中原則25。

 

原則20

避免返回對內部類對象的引用

● 若將參考型別通過公有介面暴露給外界，那麼對象的使用者即可繞過我們定義的方法和屬性來更改對象的內部結構，這會導致常見的錯誤。

 

● 共有四種不同的策略可以防止類型內部的資料結構遭到有意或無意的修改：

1）實值型別。當客戶代碼通過屬性來訪問實值型別成員時，實際返回的是實值型別的對象副本。

2）常量類型。如System.String。

3）定義介面。將客戶對內部資料成員的訪問限制在一部分功能中。

4）封裝器（wrapper）。提供一個封裝器，僅暴露該封裝器，從而限制對其中對象的訪問。

 

PS: 此原則對應於《Effective C# Second Edition》中原則26。

 

原則21

僅用new修飾符處理基類更新

● 使用new操作符修飾類成員可以重新定義繼承自基類的非虛成員。

 

● new修飾符只是用來解決升級基類所造成的基類方法和衍生類別方法衝突的問題。

 

● new操作符必須小心使用。若隨心所欲的濫用，會造成對象調用方法的二義性。

 

PS: 此原則對應於《Effective C# Second Edition》中原則33

【轉】Effective C#觀後感之提高Unity中C#代碼品質的21條準則