C#編碼標準
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
命名規范
1.利用Pascal的方式定義類型、方法名和常量 public class SomeClass 2. 對于局部變量和方法的參數使用駱駝命名法{ const int DefaultSize = 100; public SomeMethod() { } } int number; 3. 接口的名稱前面加上Ivoid MyMethod(int someNumber) {} interface IMyInterface 4. 在私有成員變量前面加上m_。對于m_后面的變量名使用駱駝命名法{  }public class SomeClass 5. 對自定義的屬性類加上后綴Attribute{ private int m_Number; } 6. 對自定義的異常類加上后綴Exception 7. 方法的命名使用動詞——對象對。例如ShowDialog() 8. 有返回值的方法的命名中要有對返回值的描述。例如GetObjectState() 9. 使用帶有說明性的變量名 a)避免單字符的變量名。例如i或t。使用類似于index或temp這樣有意義的名字。 b)對于public或protected類型的變量避免使用匈牙利表示法 c)不要所寫單詞（例如用num取代number） 10. 總是使用c＃預定義的類型而不是使用在System命名空間中的別名。例如： 使用object而不是Object 使用string 而不是String 使用int而不是Int32 11. 在使用泛型的時候，類型的首字母要大寫。當處理.NET中的Type類型的時候，保留Type后綴。  //正確public class LinkList<K,T> {}//避免public class LinkList<KeyType,DataType>{}13. 避免通過全限定方式使用類型名稱，使用using關鍵字。 14. 避免在一個命名空間中使用using關鍵字 15. 把所有系統框架提供的命名空間組織到一起，把第三方提供的命名空間放到系統命名空間的下面 16. 使用代理推導而不要顯示的實例化一個代理 17. 維護嚴格的代碼縮進。不要使用tabs或非標準的縮進，例如一個空格。推薦的縮進市3到4個空格。 18. 在和你的代碼縮進處于同一個級別處為該代碼添加注釋 19. 所有的注釋都應該通過拼寫檢查。注釋中的錯誤拼寫意味著開發進度的延緩 20. 所有類成員變量應該被聲明在類的頂部，并用一個空行把他們和方法以及屬性的聲明區分開 21. 在最靠近一個局部變量被使用的地方聲明該局部變量 22. 一個文件名應該能夠反映它所對應的類名 23. 當使用一個部分類并把該類分布到不同的文件中時，在每一個文件名末尾都加上該文件實現的部分在類整體中扮演的作用。 24. 總是要把“{”放在新的一行。 編碼實踐 1. 避免在同一個文件中放置多個類 2. 一個文件應該只向在一個命名空間內定義類型。避免在一個文件中使用多個命名空間 3. 避免在一個文件內些多余500行的代碼 4. 避免寫超過25行代碼的方法 5. 避免寫超過5個參數的方法。如果要傳遞多個參數，使用結構 6. 一行不要超過80字符 7. 不要手動去修改任何機器生成的代碼 a)如果修改了機器生成的代碼，修改你的編碼方式來死適應這個編碼標準 b)盡可能使用partial classes特性，以提高可維護性 8. 避免對那些直觀的內容作注釋。代碼本身應該能夠解釋其自身的含義。由可讀的變量名和方法名構成的優質代碼應該不需要注釋。 9. 注釋應該只說明操作的一些前提假設、算法的內部信息等內容。 10. 避免對方法進行注釋 a)使用充足的外部文檔對API進行說明 b)只有對那些其他開發者的提示信息才有必要放到方法級的注釋中來 11. 除了0和1，絕對不要對數值進行硬編碼，通過聲明一個常量來代替該數值 12. 只對那些亙古不變的數值使用const關鍵字，例如一周的天數 13. 避免對只讀（read－only）的變量使用const關鍵字。 14. 對每一個假設進行斷言。平均起來，每5行應有一個斷言。 15. 每一行代碼都應該以白盒測試的方式進行審讀。 16. 只捕捉那些你自己能夠顯示處理的異常 17. 如果在catch語句塊中需要拋出異常，則只拋出該catch所捕捉到的異常（或基于該異常而創建的其他異常），這樣可以維護原始錯誤所在的堆棧位置。 catch(Exception exception) 18. 避免利用返回值作為函數的錯誤代碼{ MessageBox.Show(exception.Message); throw;//或throw exception; } 19. 避免自定義異常類 20. 當自定義異常類的時候 a)讓你自定義的異常類從Exception類繼承 b)提供自定義的串行化機制 21. 避免在一個程序集中定義多個Main（）方法 22. 只把那些絕對需要的方法定義成public，而其他的方法定義成internal 23. 避免friend assermblies，因為這回增加程序集之間的耦合性 24. 避免讓你的代碼依賴于運行在某個特定地方的程序集 25. 在application assembly中最小化代碼量。使用類庫來包含業務邏輯 26. 避免顯示指定枚舉的值 //正確 27. 避免為枚舉指定一個類型public enum Color { Red,Green,Blue } //錯誤 public enum Color { Red=1,Green=2,Blue=3 } //避免 28. 對于if語句，總使用一對{}把下面的語句塊包含起來，哪怕只有一條語句也是如此public enum Color:long { Red,Green,Blue } 29. 避免使用三元條件操作符 30. 避免利用函數返回的Boolean值作為條件語句。把返回值賦給一個局部變量，然后再檢測 31. 總是使用以零為基數的數組 32. 總是使用一個for循環顯示的初始化一個引用成員的數組 33. 使用屬性來替代public或protected類型的成員變量 34. 不要使用繼承下來的new操作符，使用override關鍵字覆寫new的實現 35. 在一個非密封（non－sealed）類中，總是把那些public和protected的方法定義為virtual 36. 除非為了和其他語音進行互動，否則絕對不要使用不安全的代碼 37. 避免顯示類型轉換。使用as關鍵字安全的轉換到另一個類型 Dog dog = new GermanShepherd() 38. 在調用一個代理前，總是檢查它是否為nullGermanShepherd shepherd = dog as GermanShepherd; if(shepherd != null) { }39. 不要提供public的事件成員變量。改用Event Accessor 40. 總是使用接口 41. 接口和類中方法和屬性的比應該在2：1左右 42. 避免只有一個成員的接口 43. 努力保證一個接口有3～5個成員 44. 不要讓一個接口中成員的數量超過20，而12則是更為實際的限制。 45. 避免在接口中包含事件 46. 當使用抽象類的時候，提供一個接口 47. 在類繼承結構中暴露接口 48. 推薦使用顯示接口實現 49. 從來不要假設一個類型支持某個接口。在使用前總是要詢問一下。 SomeType obj1;IMyInterface obj2;//Some code to initialize,then:obj2 = obj1 as IMyInterface;if(obj2 != null){ obj2.Method(); }else{ //handle error in expected interface}50.不要硬編碼向用戶顯示的字符串。要使用資源 int number = SomeMethod()switch(number){ case 1: Trace.WriteLine("case 1:"); break; case 2: Trace.WriteLine("case 2:"); break; default: Debug.Assert(false) break;}60. 除了在一個構造函數中調用其他的構造函數之外，不要使用this關鍵字 該文章在 2017/2/7 18:53:52 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
