C#編碼標準
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
命名規(guī)范
1.利用Pascal的方式定義類型、方法名和常量 public class SomeClass 2. 對于局部變量和方法的參數(shù)使用駱駝命名法{ 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后綴。 //正確 12. 使用有意義的名字定義命名空間。例如產(chǎn)品名或者公司名public class LinkList<K,T> {} //避免 public class LinkList<KeyType,DataType> {} 13. 避免通過全限定方式使用類型名稱,使用using關鍵字。 14. 避免在一個命名空間中使用using關鍵字 15. 把所有系統(tǒng)框架提供的命名空間組織到一起,把第三方提供的命名空間放到系統(tǒng)命名空間的下面 16. 使用代理推導而不要顯示的實例化一個代理 17. 維護嚴格的代碼縮進。不要使用tabs或非標準的縮進,例如一個空格。推薦的縮進市3到4個空格。 18. 在和你的代碼縮進處于同一個級別處為該代碼添加注釋 19. 所有的注釋都應該通過拼寫檢查。注釋中的錯誤拼寫意味著開發(fā)進度的延緩 20. 所有類成員變量應該被聲明在類的頂部,并用一個空行把他們和方法以及屬性的聲明區(qū)分開 21. 在最靠近一個局部變量被使用的地方聲明該局部變量 22. 一個文件名應該能夠反映它所對應的類名 23. 當使用一個部分類并把該類分布到不同的文件中時,在每一個文件名末尾都加上該文件實現(xiàn)的部分在類整體中扮演的作用。 24. 總是要把“{”放在新的一行。 編碼實踐 1. 避免在同一個文件中放置多個類 2. 一個文件應該只向在一個命名空間內(nèi)定義類型。避免在一個文件中使用多個命名空間 3. 避免在一個文件內(nèi)些多余500行的代碼 4. 避免寫超過25行代碼的方法 5. 避免寫超過5個參數(shù)的方法。如果要傳遞多個參數(shù),使用結構 6. 一行不要超過80字符 7. 不要手動去修改任何機器生成的代碼 a)如果修改了機器生成的代碼,修改你的編碼方式來死適應這個編碼標準 b)盡可能使用partial classes特性,以提高可維護性 8. 避免對那些直觀的內(nèi)容作注釋。代碼本身應該能夠解釋其自身的含義。由可讀的變量名和方法名構成的優(yōu)質(zhì)代碼應該不需要注釋。 9. 注釋應該只說明操作的一些前提假設、算法的內(nèi)部信息等內(nèi)容。 10. 避免對方法進行注釋 a)使用充足的外部文檔對API進行說明 b)只有對那些其他開發(fā)者的提示信息才有必要放到方法級的注釋中來 11. 除了0和1,絕對不要對數(shù)值進行硬編碼,通過聲明一個常量來代替該數(shù)值 12. 只對那些亙古不變的數(shù)值使用const關鍵字,例如一周的天數(shù) 13. 避免對只讀(read-only)的變量使用const關鍵字。 14. 對每一個假設進行斷言。平均起來,每5行應有一個斷言。 15. 每一行代碼都應該以白盒測試的方式進行審讀。 16. 只捕捉那些你自己能夠顯示處理的異常 17. 如果在catch語句塊中需要拋出異常,則只拋出該catch所捕捉到的異常(或基于該異常而創(chuàng)建的其他異常),這樣可以維護原始錯誤所在的堆棧位置。 catch(Exception exception) 18. 避免利用返回值作為函數(shù)的錯誤代碼{ MessageBox.Show(exception.Message); throw;//或throw exception; } 19. 避免自定義異常類 20. 當自定義異常類的時候 a)讓你自定義的異常類從Exception類繼承 b)提供自定義的串行化機制 21. 避免在一個程序集中定義多個Main()方法 22. 只把那些絕對需要的方法定義成public,而其他的方法定義成internal 23. 避免friend assermblies,因為這回增加程序集之間的耦合性 24. 避免讓你的代碼依賴于運行在某個特定地方的程序集 25. 在application assembly中最小化代碼量。使用類庫來包含業(yè)務邏輯 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. 避免利用函數(shù)返回的Boolean值作為條件語句。把返回值賦給一個局部變量,然后再檢測 31. 總是使用以零為基數(shù)的數(shù)組 32. 總是使用一個for循環(huán)顯示的初始化一個引用成員的數(shù)組 33. 使用屬性來替代public或protected類型的成員變量 34. 不要使用繼承下來的new操作符,使用override關鍵字覆寫new的實現(xiàn) 35. 在一個非密封(non-sealed)類中,總是把那些public和protected的方法定義為virtual 36. 除非為了和其他語音進行互動,否則絕對不要使用不安全的代碼 37. 避免顯示類型轉換。使用as關鍵字安全的轉換到另一個類型 Dog dog = new GermanShepherd() 38. 在調(diào)用一個代理前,總是檢查它是否為nullGermanShepherd shepherd = dog as GermanShepherd; if(shepherd != null) {} 39. 不要提供public的事件成員變量。改用Event Accessor 40. 總是使用接口 41. 接口和類中方法和屬性的比應該在2:1左右 42. 避免只有一個成員的接口 43. 努力保證一個接口有3~5個成員 44. 不要讓一個接口中成員的數(shù)量超過20,而12則是更為實際的限制。 45. 避免在接口中包含事件 46. 當使用抽象類的時候,提供一個接口 47. 在類繼承結構中暴露接口 48. 推薦使用顯示接口實現(xiàn) 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. 除了在一個構造函數(shù)中調(diào)用其他的構造函數(shù)之外,不要使用this關鍵字 該文章在 2017/2/7 18:53:52 編輯過 |
關鍵字查詢
相關文章
正在查詢... |