IT工程師數位筆記本

值得推薦的一本書，適合初中級C#開發人員

第1章 C#語言元素

原則1：盡可能的使用屬性（property），而不是數據成員（field）

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

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

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

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

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

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

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

　　5）屬性也可以定義為接口。

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

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

　　無論何時，需要在類型的公有或保護接口中暴露數據，都應該使用屬性。如果可以也應該使用索引器來暴露序列或字典。現在多投入一點時間使用屬性，換來的是今后維護時的更加游刃有余。

原則2：為你的常量選擇readonly而不是const

　　對于常量，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：始終提供ToString()

　　1. 人最容易理解的是字符串，而Object.ToString的默認行為是返回類型名，正確的實現ToString有利于調試和UI等。

　　2. Console.WriteLine和String.Format等都支持IFormattable接口，注意IFormattable.ToString和Object.ToString的兼容。

原則6：區別值類型數據和引用類型數據

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

原則7：選擇恒定的原子值類型數據

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

原則8：確保0對于值類型數據是有效的

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

原則9：明白幾個相等運算之間的關系

　　1. 對于ValueType:（對應struct）

 　　public override bool Equals(object obj);

　　它的實現主要是通過反射來對比各個字段，因此這個默認實現效率很低。ValueType的默認實現中，并不能直接將兩個二進制塊進行memcmp，因為形如struct A{ string s; }這樣的結構，二進制層次上的對比是沒有意義的。事實上，C#編譯器也沒有提供自動生成T.Equals的服務（即對于用戶沒有提供Equals實現的struct，編譯器何不自動生成逐字段對比的C#代碼？），原因不明。

　　所以，如果特定struct性能攸關，應該手工實現Equals進行逐字段比較以獲得更佳性能。另外考慮實現語法糖operator==來調用Equals。

　　2. 對于Object: （對應class）

　　public static bool ReferenceEquals(object objA, object objB);

　　public static bool Equals(object objA, object objB);

 　　public virtual bool Equals(object obj);

　　public static bool operator == (object objA, object objB);

　　Object基類中的默認實現全是引用比較，即用于判斷是否是同一對象。其中ReferenceEquals提供最底層實現，operator ==調用ReferenceEquals, static Equals進行對象非空驗證然后調用virtual Equals, 而virtual Equals默認也是調用ReferenceEquals。

　　如果需要給引用類型提供其他比較語義，如string，則實現virtual Equals，然后重載operator ==調用virtual Equals。

原則10：明白GetHashCode()的缺陷

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

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

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

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

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

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

原則11：選擇foreach循環

　　1. foreach會自動針對不同的容器，生成不同的il碼以優化效率。例如對數組，foreach不會通過IEnumerable遍歷，而是直接使用下標。

　　2. foreach可以正確遍歷起始下標非0的數組和多維數組。下標非0數組是通過Array.CreateInstance創建的。

　　3. foreach遍歷數組，因為可以保證訪問數組的每個元素的時候不越界，故foreach對應的下標訪問實現不會有下標越界檢查的開銷。在我使用的C#3.5中測試，foreach并沒有加速效果，恐怕因為在高版本中，下標越界檢查已經移到了clr的實現中（il的ldelem），故foreach并不比for循環快。

第2章 .NET資源管理

原則12：選擇變量初始化而不是賦值語句

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

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

原則13：用靜態構造函數初始化類的靜態成員

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

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

　　● 和實例初始化一樣，也可以使用初始化器語法來替代靜態的構造函數。若只是需要為某個靜態成員分配空間，那么不妨使用初始化器的語法。而若是要更復雜一些的邏輯來初始化靜態成員變量，那么可以使用靜態構造函數。

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

原則14：使用構造函數鏈

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

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

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

原則15：使用using和try/finally來做資源清理

　　對于文件等有Close方法的IDisposable對象，應該使用Dispose方法來代替Close，因為前者還會進行GC.SuppressFinalize操作，明顯提高性能。

原則16：垃圾最小化

　　1. 頻繁調用的成員方法中如果有局部作用域的資源，嘗試把資源作為對象的成員數據。如在OnPaint中使用的Font作為成員的話就不必每次都創建。

　　2. 常用的資源考慮作為靜態對象，還可以作為屬性在get中進行延遲加載等。如Brush.Black等。

　　3. 常量性數據避免頻繁修改。如string，可以使用string.format和StringBuilder來減少垃圾。

原則17：裝箱和拆箱的最小化

　　注意將struct轉換為引用類型，都會造成裝箱。如將struct轉換為object/ValueType/interface。

原則18：實現標準的處理(Dispose)模式

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

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

　　1）若某個引用類型（值類型無所謂）的局部變量用于被頻繁調用的例程中，那么應該將其提升為成員變量。

　　2）為常用的類型實例提供靜態對象。

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

第3章 使用C#表達設計

原則19：選擇定義和實現接口而不是繼承

　　1. 接口表示“behaves like”，而繼承表示“is a”。繼承同一個基類的多個類型是相關類型，而繼承同一個接口的多個類型可以完全無關，只是都包含一組行為。

　　2. 接口的簽名相對較穩定，因為對接口的修改將影響所以實現該接口的類型；而修改繼承體系中的基類，如果有默認實現的話，派生類不一定需要調整。

　　3. 公開接口相比公開具體類，前者暴露更少的實現細節。

原則20：明辨接口實現和虛函數重載的區別

　　實現接口時，接口方法的具體修飾如virtual、abstract等可以自由設置。

原則21：用委托來表示回調

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

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

　　2）委托允許我們在運行時配置目標并通知多個客戶對象。委托對象中包含一個方法的應用，該方法可以是靜態方法，也可以是實例方法。也就是說，使用委托，我們可以和一個或多個在運行時聯系起來的客戶對象進行通信。 

　　3）由于回調和委托在C#中非常常用，以至于C#特地以lambda表達式的形式為其提供了精簡語法。

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

原則22：用事件定義對外接口

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

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

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

原則23：避免返回內部類對象的引用

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

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

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

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

　　3）定義接口。將客戶對內部數據成員的訪問限制在一部分功能中。

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

原則24：選擇申明式編程而不是命令式編程

　　主要指特性的應用（System.Attribute的派生類）。例如序列化特性等

原則25：讓你的類型支持序列化

 　　任何可序列化的類型要求其主要數據成員也應該可序列化，所以考慮是否要讓類型支持序列化的時候，還需要考慮將來該類型是否有可能被用于其他可序列化類型作為其成員（即放棄A的序列化能力，會給包含A的可序列化類型B帶來麻煩）。一般只有UI對象等不需要序列化能力，所以大部分類型都應該盡可能的支持序列化。

原則26：用IComparable和IComparer實現對象的順序關系

 　　排序過程中的比較操作頻率很高，需要盡可能高效，注意減少不必要的裝箱和使用IComparer代替委托。

原則27：避免使用ICloneable

　　1. 值類型不支持多態，且本身的賦值操作符效率很高，一般不需要實現ICloneable。

　　2. 引用類型實現ICloneable的時候，考慮像C++那樣，先實現拷貝構造函數，然后用拷貝構造函數實現Clone。

原則28：避免轉換操作

　　建議使用單參數構造函數代替類型轉換。首先，隱式類型轉換由于過于隱蔽容易造成bug需要嚴格控制，如C++中慎用operator T和要求單參構造函數聲明為explicit，都是為了限制隱式類型轉換，規則應用到C#后，還剩下兩種選擇，即單參構造函數和explicit的類型轉換，前者正是本條款提倡的，而后者，只有當轉換后的類型具有常量性的時候可以使用（如果轉換為可以修改類型，因為返回的對象是臨時對象，應用在這個臨時對象的修改會無效，忽略了這點可能會產生較隱蔽的bug。如Array.Sort((int[])myListType);）。

原則29：僅在對基類進行強制更新時才使用new修飾符

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

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

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

第4章 創建二進制組件

原則30：選擇與CLS兼容的程序集

 　　要讓程序集能夠被不同.Net語言訪問（語言互操作性），程序集需要與CLS兼容。使用特性[assembly: CLSCompliant(true)]，讓編譯器檢查CLS兼容性。CLS兼容意味著，公開或保護的方法和接口與CLS兼容。

原則31：選擇小而簡單的函數

　　較小的函數比大函數有更少的局部變量，有利于JIT合理分配寄存器，有利于內聯

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

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

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

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

原則32：選擇小而內聚的程序集

　　程序集的劃分標準之一：程序集的功能應該能夠一句話概括。

原則33：限制類型的訪問

　　可以使用內部類實現公開接口等

原則34：創建大容量的Web API

　　大粒度的Web API、RPC API、腳本API等，由于載荷大，調用頻率更低，相比小粒度的API具有跨邊界通信總成本小的優點

第5章 使用框架

原則35：選擇重寫函數而不是使用事件句柄

　　面對override和event兩種事件處理選擇的時候，前者更優：

　　（1）覆蓋虛方法性能更高，還可應控制調用基類方法觸發event的時機。

　　（2）event中的方法鏈是動態表，有可能因未知的原因導致方法沒有被調用。如方法鏈的前端有異常拋出或委托對象被清空等。

原則36：利用.Net運行時診斷

　　1. 在編譯時，可以通過編譯選項控制System.Diagnostics.Trace和System.Diagnostics.Debug的開關。

　　2. 在運行時，可以通過配置文件配置Trace的輸出目標文件和等級等。

原則37：使用標準的配置機制

　　除.Net默認的配置文件外，還可以利用Xml序列化實現簡單的讀寫配置

原則38：使用和支持數據綁定

　　應該盡量利用UI庫提供的數據綁定功能，它能夠大幅簡化代碼邏輯。數據綁定允許配置數據源和目標屬性、允許控制源和目標類型不匹配時的轉換方式，數據綁定能夠正確處理數據同步的時機，避免了在多處編寫重復的同步代碼。

原則39：使用.Net驗證

原則40：根據需求選擇集合

原則41：選擇DataSet而不是自定義的數據結構

　　DataSet由于有數據庫的視圖、約束、事務等邏輯，很容易和UI結合。缺點是DataSet中表項是弱類型。

原則42：使用特性進行簡單的反射

 　　特性的一種用法：給類型或成員打上指定特性作為標記，用于在反射時進行類型、方法的篩選。

原則43：請勿濫用反射

 　　反射是晚綁定，容易引入人為bug，除非對動態編碼有高要求，否則盡量優先考慮用工廠模式、接口、委托等方案替代反射

原則44：創建應用程序特定的異常類

　　1. 選擇拋出異常是因為clr拋出的異常信息有限，以及有的錯誤情況如不及時反饋會在后期爆發時無從追查。

　　2. 外部會根據錯誤原因做區別處理時，才考慮使用特定類型的異常。

　　3. 使用新異常類型來表達特殊錯誤，相比始終拋出System.Exception并用描述字符串區分錯誤原因的方案，后者因為依賴于字符串無強類型保證，不利于重構且易引起bug。

第6章 雜項討論

原則45：選擇強異常來保護程序

　　1. 基本保證：拋出異常后，無資源泄漏且對象都處在有效狀態。垃圾收集和using避免了資源泄漏，所以只需要注意不要因異常打亂執行流程而導致對象狀態破壞。

　　2. 強保證：拋出異常導致操作中斷后，對象狀態應該和操作前相同。C++實踐：拷貝對象->修改拷貝后對象->交換拷貝和源對象。

　　3. 無拋保證：不拋出異常。C#中至少有3組方法不應該拋出異常：

　　（1）終結器（析構函數）。終結器被垃圾回收線程調用，拋出異常將直接導致程序結束。C++也禁止析構函數拋出異常，理由是構成雙異常的情況下導致程序崩潰。

　　（2）Dispose方法。該方法一般嵌套在finally語句塊中，如果finally語句塊因為有其他異常拋出才被動執行，那語句塊中的Dispose再拋出異常將導致前一個異常被覆蓋（C#面對雙異常，采取后者覆蓋前者的策略），結果最初的異常信息丟失。

　　（3）委托方法。委托默認是多播委托，如果方法鏈中的一個方法拋出異常，后面的方法將不被調用。

原則46：最小化與其它非托管代碼的交互

　　1. interop在數據傳輸方面存在marshal開銷。使用blittable類型（基礎類型、基礎類型數組、基礎類型的struct包裝）可以直接傳輸避免marshal。聲明In、Out特性和選擇最合適的聲明也有利于提高效率。

　　2. interop在托管和非托管代碼間切換的開銷。存在三種選擇：

　　（1）Com Interop。因為屬性頻繁使用造成交互頻繁，效率低。適合和Com交互。

　　（2）Platform Invoke。效率高，但需要聲明每個函數，且無自然的面向對象語法。適合和C API交互。

　　（3）C++/CLI。易于將C++的類型包裝成托管類型。適合和C++交互。

　　3. interop復雜的語法增加了開發成本。

原則47：選擇安全的代碼

　　1. unsafe代碼塊最好集中到單獨的程序集。（為何？如果要求集中到單獨的AppDomain我明白。）

　　2. 為部分受信程序集提供隔離存儲區。如Web上的代碼。

原則48：了解更多的工具和資源

　　單元測試（NUnit）、代碼分析（FxCop）、IL反匯編（ILDasm）、官方網站和社區、.Net和C#源碼（rotor）等。

原則49：為C#2.0做好準備

原則50：了解ECMA標準