你不知道的常用 代碼分析 規范

visual studio有個功能，代碼分析，一般開發完畢后，除了處理常規的“錯誤列表”顯示的“錯誤”和“警告”，我們更加應該注意的是，運行代碼分析功能，規范我們的代碼，因為不好的編碼習慣，在沒有人指出和沒有團隊氛圍的開發中，很多時候都是一路不規范到底

visual studio菜單的“分析”-》“對***運行代碼分析”或者在解決方案的類庫右擊選擇代碼分析如果為了強迫自己養成良好的c#微軟規范的習慣，我們可以右擊類庫屬性，找到最后一行標簽“代碼分析”，并在對應右側明細的“規則集”->"運行此規則集"下拉框中選擇Microsoft的所有規則。當然如果你需要每次生成代碼時讓vs自動幫我們執行代碼分析，也可以勾選上復選框“生成時啟動代碼分析”，在長時間的編碼中如果每次都運行代碼分析，我們的代碼會越來越規范和高效率我找了以前的很多代碼和網上下載的代碼，以及公司的一些朋友的代碼，逐一代碼分析后，總結了如下常規開發中一般會遇到的規范問題，這些都不是錯誤或者警告，但是對于需要提高自身修養的程序員來說，這是必修課，當然本文只是拋磚引玉，更多的規范在微軟的官方文檔中都有，只是很多永遠不會遇到MSDN:http://msdn.microsoft.com/zh-cn/library/dd264939(v=vs.100).aspx下面我將最最最常用的規范問題，總結在一段程序當中（相當簡單的程序），朋友們可以不運行代碼分析憑借自己的經驗來判斷，到底有多少處不規范的地方我敢保證，對于常規的要求不是很嚴格的開發，以下這些問題或多或少都會在您的代碼中出現調用入口：

 1 static void Main(string[] args) 2         { 3             try 4             { 5                 Class_Test test1 = new Class_Test(); 6                 test1.Fun1(); 7             } 8             catch (Exception ex) 9             {10                 Console.WriteLine(ex.ToString());11             }12             Console.ReadLine();13         }

（代碼1）

核心代碼（為了查看方便把多個類放到同一個文件）：

 1 namespace TestBLL.Class_Test 2 { 3     public class Class_Test 4     { 5         public void Fun1() 6         { 7             const int param1 = 10; 8             string name = param1.ToString(); 9             if (name == "")10             {11                 Console.WriteLine("empty");12             }13             else14             {15                 try16                 {17                     Class_Test2 test2 = new Class_Test2();18                     test2.Age = 25;19                     Fun_Test1("", ref test2, 100, "");20 21                     bool param2 = Boolean.Parse(name);22                     Console.WriteLine(param2);23                     List<string> list = new List<string>();24                     list.Add(name);25                 }26                 catch (Exception ex)27                 {28                     Console.WriteLine(ex.Message);29                     throw ex;30                 }31             }32         }33         public void Fun_Test1(string param1, ref  Class_Test2 param2, int param3, string Param4)34         {35             string param5 = "";36             param2.Age = 24;37             param2.Fun1(param1, Param4, ref param5);38 39         }40     }41     public class Class_Test242     {43         public int Age { get; set; }44         public string getTimeType()45         {46             string TimeType = string.Empty;47             int hour = DateTime.Now.Hour;48             if (hour >= 1 && hour < 5)49                 TimeType = "凌晨";50             else if (hour >= 5 && hour < 11)51                 TimeType = "早上";52             return TimeType;53         }54         public void Fun1(string param, string param1, ref string param2)55         {56             # region57             for (int i = 0; i < 10; i++)58             {59                 string name = "yhc";60                 Console.WriteLine(name);61             }62             //此處省略99個如上for循環代碼塊63             #endregion64             Fun2();65             Console.WriteLine(param);66         }67         PRivate void Fun2()68         {69             Console.WriteLine();70         }71     }72     public class Class_Test373     {74         public static void Fun1()75         {76         }77     }78     public struct StructTest<T>79     {80         public List<T> rows;81     }82 }

（代碼2）

代碼分析后有N個警告,大多數都要引起重視1、CA2210程序集應具有有效的強名稱用強名稱密鑰對 'TestBLL.dll' 進行簽名。　　

• 微軟認為為程序集添加簽名，防止程序集被惡意篡改，是需要做得工作，但是大多數時候我們都不會做簽名，畢竟很多時候是為企業內部定制軟件或者掛在　　服務端的web服務器上，不做任何的傳輸共享
• 如果您需要為程序集添加簽名，詳細參考地址：http://m.survivalescaperooms.com/cpcpc/archive/2011/01/17/2123086.htmlhttp://m.survivalescaperooms.com/yangecnu/archive/2013/01/01/2841235.html
• 如果你覺得沒有必要，可以在“操作”中選擇“禁止顯示此消息”

2、CA1014用 CLSCompliantAttribute 標記程序集使用 CLSCompliant(true)來標記 'TestBLL.dll'，因為它公開外部可見的類型。

• 如果您的程序集需要跨編程語言使用，并且您知道cls（公共語言規范）的概念，那么您必須處理這條警告，因為必須用CLSCompliantAttribute顯式指示 CLS 符合性，讓您的程序集在跨語言使用時不會出現沖突或者異常，比如vb中函數是不區分大小寫，如果您不處理這條警告，在編寫您的程序集時，您在代碼同一個Class中有兩個方法，只是大小寫不同，例如Fun和fun，那么不會有任何警告和問題，但是被vb中調用就會報異常
• 如果您需要使用CLSCompliantAttribute 來標記程序集，只需要在AssemblyInfo.cs文件中添加命名空間引用using System;并加上代碼[assembly:CLSCompliant(true)]即可詳細參考地址：http://m.survivalescaperooms.com/mywebname/articles/598460.htmlhttp://msdn.microsoft.com/zh-cn/library/ms182156
• 如果你覺得沒有必要，可以在“操作”中選擇“禁止顯示此消息”

3、 CA1709標識符的大小寫應當正確更正程序集名稱 'TestBLL.dll' 中“BLL”的大小寫，將其改為“Bll”。（命名空間、類名等都是如此）

• 我們都知道Camel和Pascal命名規則，也會經常按照此規則編寫代碼，但是還是會經常寫出類似TestBLL的命名代碼，這邊很多人忽略的是雙字母單詞，一般的vs分析會檢測您的命名中是否存在雙字母單詞（雙字母單詞固定就那么多），如果存在則不會報錯比如：采用Pascal命名規范給程序集命名TestDB，那么不會發出警告，因為DB是屬于雙字母單詞，如果采用Pascal命名規則，那么一般三個或者三個以上字符是不允許出現全部大寫的，比如這里的TestBLL中的"BLL"
• 詳細參考地址：http://msdn.microsoft.com/query/dev12.query?appId=Dev12IDEF1&l=ZH-CN&k=k(CA1709);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.5)&rd=true

4、CA1707標識符不應包含下劃線從命名空間名稱“TestBLL.Class_Test”中移除下劃線。

• 在.NET平臺下，微軟不建議使用匈牙利命名法，所以在這里有下劃線的存在也會拋出警告,后面的類名Class_Test2、Class_Test3，以及方法名Fun_Test1都是不規范的
• 詳細參考地址：http://msdn.microsoft.com/library/ms182245(VS.100).aspx

5、CA1724類型名不應與命名空間沖突類型名 'ClassTest' 與命名空間名稱“TestBLL.ClassTest”整體或部分沖突。請更改其中任一名稱以消除沖突。

• 在代碼2中的類型名 'ClassTest' 與命名空間名稱“TestBLL.ClassTest”發生了部分沖突，這樣會使庫的可用性下降
• 詳細參考地址：http://msdn.microsoft.com/zh-cn/library/vstudio/ms182257(v=vs.110).aspx

6、CA1305指定 IFormatProvider由于 'int.ToString()' 的行為可能會因當前用戶的區域設置不同而不同，請將 'ClassTest.Fun1()' 中的此調用替換為對 'int.ToString(IFormatProvider)' 的調用。如果要向用戶顯示 'int.ToString(IFormatProvider)' 的結果，請指定 'CultureInfo.CurrentCulture' 作為“IFormatProvider”參數。或者，如果軟件將存儲和訪問此結果(例如，當將此結果保留到磁盤或數據庫中時)，則指定 'CultureInfo.InvariantCulture'。

• 代碼位置：代碼2中的8行，string name = param1.ToString();
• 在數據具有邏輯性判斷或者存儲數據的時候，一些區域化參數一定不要忘記，幾乎所有時候我們都是基本本國開發，從來不會考慮這些參數，包括ToString(),ToUpper(),DateTime.ToShortDateString(),DateTime.ToString()等等，所以也從來沒有問題,那是因為系統會選擇你當前線程的CultureInfo（和你強制加參數CultureInfo.CurrentCulture效果一樣）。雖然用戶界面UI看上去很智能，但是帶來的一個問題是：如果你的數據是純邏輯性判斷或者存儲的時候，請不要偷懶，因為邏輯判斷的值或者存儲起來的值是需要一個固定的不需要隨著區域而變化的值，否則服務端將各種異常奇怪現象，此時就要設置'CultureInfo.InvariantCulture',因為它是不依賴于區域性（固定）的 System.Globalization.CultureInfo 對象
• 詳細參考地址：http://weishangxue.blog.163.com/blog/static/2157518820117193125196/
• 修改為：string name = param1.ToString(CultureInfo.InvariantCulture);

7、CA1820使用字符串長度測試是否有空字符串使用“String.IsNullOrEmpty”調用來替換 'ClassTest.Fun1()' 中的 'string.Operator ==(string, string)' 調用。

• 代碼未知：代碼2中的9行，if (name == "" )
• 判斷字符串是否為空，請不要再用equals 或者== “”了，因為字符串的equal或者==（操作符重載）都是重載過的，object的equal或者==都是比較是否引用相同，而string重載后則是比較值了，首先可以確定的是String.IsNullOrEmpty或者String.Length肯定比equals或者==“”效率高，因為用ILDASM查看il代碼時，發現執行的il代碼行數前者比后者少，這是其次，最重要的是用ILSpy反編譯String類的Equals代碼后發現，內部做了太多操作

1 public bool Equals(string value)2         {3             if (this == null)4             {5                 throw new NullReferenceException();6             }7             return value != null && (object.ReferenceEquals(this, value) || (this.Length == value.Length && string.EqualsHelper(this, value)));8         }

1 public static bool IsNullOrEmpty(string value)2         {3             return value == null || value.Length == 0;4         }

• 詳細參考地址：http://msdn.microsoft.com/library/ms182279(VS.100).aspx
• 修改為：if (string.IsNullOrEmpty(name) )

8、CA2200再次引發以保留堆棧詳細信息'ClassTest.Fun1()' 再次引發捕獲的異常并將其顯式地指定為一個參數。請改用不帶參數的“throw”以保留該異常最初引發時所在的堆棧位置。

• 代碼位置：代碼2中的29行，throw ex;
• 這邊有兩個問題，第一：捕捉異常最好不用直接用Exception類型來捕捉，因為這樣系統會遍歷所有異常信息來查找匹配的異常，導致的后果就是一旦發生異常，系統就會卡頓很久，最好的做法是由上到下先捕捉可能會發生的異常類型，最后再捕捉異常類型基類Exception，常見的異常類并不是很多，如果有時候您根本不知道你應該寫什么異常類型，那么您先保存下常用的異常類列表，使用時再去查看，時間長了自然就知道了，如下：