前言
建議4、TryParse比Parse好
建議5、使用int?來確定值類型也可以為null
建議6、差別readonly和const的使用方法
建議7、将0值設為枚舉的預設值
建議8、避免給枚舉類型的元素提供顯式的值
建議9、習慣重載運算符
建議4、TryParse比Parse好
如果注意觀察，除string之外的所有的基元類型。會發現它們都有兩個将字元串轉換為自身類型的方法：Parse和TryParse。以類型double為例。
兩者最大的差別是，如果字元串格式不滿足轉換的要求，Parse方法将會引發一個異常；TryParse方法則不會引發異常，它會傳回false,同時将result置為0。
Parse轉換失敗會運作時報錯
而TryParse轉換失敗傳回false，将其指派為0
TryParse和Parse兩者都執行成功，那麼TryParse的性能要比Parse性能稍微好一點，但是如果抛出異常，那麼TryParse的性能比Parse提升了不少額。
不過這裡并不建議為所有的類型都提供TryParse模式，隻有在考慮到Parse會帶來明顯的性能損耗時，才建議使用TryParse。
建議5、使用int?來確定值類型也可以為null
基元類型為什麼需要為null?需要考慮以下兩個場景：
1、資料庫中一個int字段可以被設定為null。在C#中，值被取出來後，為了将它指派給int類型，不得不首先判斷一下它是否為null。如果将null直接指派給int類型，會引發異常。
2、在一個分布式系統中，伺服器需要接收并解析來自用戶端的資料。一個int型資料在傳輸的過程中可能會丢失或者被篡改。轉型失敗後應該儲存為null值，而不是提供一個預設值。
類似的場景還有很多，在這裡不進行更詳盡的列舉。在.NET2.0開始，便提供了一個額外的類型：可以為空的類型Nullable<T>。
通過定義可以發現，它是一個結構體。因為是結構體，是以隻有值類型才可以作為“可以為空的類型”（引用類型本身可以為null）。一個可以為空的int類型可以表示為
它也可以表示為
當然之後可以這樣進行應用
建議6、差別readonly和const的使用方法
建議7、将0值設為枚舉的預設值
允許使用的枚舉類型有byte、sbyte、short、ushort、int、uint、long、ulong、應該始終将0值作為枚舉的預設值。接下來我們通過示例來說明問題
在調用的時候發現
結果竟然出來了一個0，讓人感覺怎麼是第八個值出現了。是以建議将0設定為枚舉的預設值。
建議8、避免給枚舉類型的元素提供顯式的值
一般情況下，沒有必要給枚舉類型的元素提供顯式的值。建立枚舉的理由之一，就是為了代替使用實際的值。不正确的為枚舉類型的元素設定顯式的值，會帶來意想不到的錯誤。
假如我們在如上枚舉中，又添加了一個TempValue的元素。可以先猜測一下此時TempValue的值會是多少？
通過調試可以發現。當編譯器發現元素ValueTemp的時候，它會自動在Tuesday=2的基礎上+1，是以ValueTemp的值和Wednesday的值都是3。可見，枚舉元素允許設定重複的值。
注意： 本建議也有例外的情況。例如，當為一個枚舉類型指定System.FlagsAttribute屬性就意味着可以為這些值執行And、Or、Not、Xor按位運算了，這樣一來，枚舉的每個元素的值就要求都是2的若幹次幂，指數依次遞增。
按位運算在這裡不多說了，詳情可以檢視 http://www.cnblogs.com/NetBelieve/archive/2012/07/30/2615006.html
建議9、習慣重載運算符
在開發的過程中，應該習慣于使用微軟提供給我們的文法特性。我想大部分人應該喜歡看到這樣的文法特性：
而不是看到下面的文法：
是以我們在自定義類型的時候，也可以考慮看看類型是否可以使用運算符重載。
那現在我們來進行調用的時候就友善了很多。