這篇文章，將《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條準則的總結式思維導圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

is : 檢查一個物件是否兼容於其他指定的型別,並返回一個Bool值,永遠不會丟擲異常。

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

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

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

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

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

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

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

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

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

● 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。

● 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。

將C#程式碼翻譯成可執行的機器碼需要兩個步驟。

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

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

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

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

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

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

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