.NET中的命名规则

雨点打透心脏的1/2处 2022-06-06 02:21 195阅读 0赞

1.  名称空间的命名　   
2.    
3.  　　 命名名称空间的一般规则如下：   
4.  　　 CompanyName.TechnologyName  
5.  　　这样，我们看到的名称空间应该是这样的：　　  
6.  　 　Microsoft.Office  
7.  　　 PowerSoft.PowerBuilder 　 　　 　　 　　 　　 　　 　　 　　 　　 　　 　   
8.    
9.  　　注意：这只是一个原则。第三方公司可以选择其它的名字。  
10. 　　避免用公司名称或其它著名品牌的名称作为名称空间的前缀，这样会造成两个公布的名称空间有同一个名称的可能性。  
11. 　　例如： 将微软提供的Office自动类命名为Microsoft.Office  
12.   
13. 　　使用Pascal大写方式，用逗号分隔逻辑成分。  
14. 　　例如：Microsoft.Office.PowerPoint  
15.   
16. 　　如果你的品牌使用的是非传统大写方式，那么一定要遵循你的品牌所确定使用的大写方式，即使这种方式背离了通常的名称空间大写规则。  
17. 　　例如：NeXT.WebObjects  
18. 　　　　　ee.cummings  
19.   
20.   
21. 类和类成分的命名  
22.   
23. 　　类的命名原则是用名词或名词短语命名类，使用Pascal大写。减少类名中缩写的使用量。不要使用任何类前缀（比如C），不要使用带下划线的字符。  
24. 　　例如：**public** **class** FileStream \{\}  
25. 　　　　　 **public** **class** Button \{\}  
26. 　　　　　 **public** **class** String \{\}   
27.   
28. 变量的命名  
29.   
30. 　　名称中各单词首字母均为大写。  
31. 　　例如：FindLastRecord  
32. 　　　　　 RedrawMyForm  
33. 　　在内部范围中避免使用与外部范围中的名称相同的名称。若访问错误变量，则会产生错误结果。若变量与同一名称的关键字冲突，则必须在关键字前加适当的类型库以作标识。   
34. 　　例如：若有一个名为 date 的变量，只能通过调用 System.Date 来使用内部 Date 函数。   
35.   
36. 函数和方法的命名  
37.   
38. 　　函数和方法的命名应该以动词开始，使用Pascal大写。不要使用带下划线的字符。  
39. 　　例如：InitNameArray  
40. 　　　　　 CloseDialog  
41.   
42. 接口命名原则  
43.   
44. 　　使用名词或名词短语，或者描述行为的形容词来命名接口,使用Pascal大写。 减少接口名中缩写的使用量，在接口名前加前缀I，以表示这个类型是一个接口。  
45. 　　 例如： IComponent（描述性名词）  
46. 　　　　 　 ICustomAttributeProvider（名词短语）  
47. 　　 　　　 IPersistable（形容词）  
48.   
49. 参数的命名 　　  
50.   
51. 　　使用描述性参数名。参数名应该具有足够的描述性，这样在大多数情况下参数名和它的种类可以用来确定它的意思。根据参数的意思来命名参数，而不是根据参数的种类来命名。我们希望开发工具可以用很方便的方式提供关于参数种类的信息，这样参数名可以得到更好的使用，可以对语义而不是对种类进行描述。但是偶尔使用根据类型命名的参数名也是完全可以的。不要使用保留参数。如果在下一个版本中需要更多的数据，可以增加进来。  
52. 　　例如：Type GetType (string typeName)  
53. 　　　　　string Format (string format, object \[ \] args)   
54.   
55. 属性的命名  
56.   
57. 　　用名词或名词短语命名属性，属性与类型要一样。 用与一个类型的名称相同的名字来命名属性时，就使这个属性的类型成为那个类型。虽然听起来有些奇怪，但这是正确的。   
58. 　　例如：**public** **enum** Color \{...\}  
59. 　　　　　 **public** **class** Control \{  
60. 　　　　　 **public** Color Color \{get \{...\} set \{...\}\}  
61. 　　　　　 \}  
62.   
63. 事件的命名  
64.   
65. 　　用EventHandloer后缀命名事件处理程序，使用名为sender和e的两个参数，Sender参数代表提出事件的对象。Sender参数永远是一个类型对象，即使它可能使用了更为特定的类型，与事件相关的状态被封装在一个名为e的事件类范例中。要使用这个类型的正确的、特定的事件类。   
66. 　　例如：**public** delegate **void** MouseEventHandler(object sender, MouseEvent e);  
67. 　　命名事件名时，需要有之前和之后的时态概念，因此要使用现在时态和过去时态（不要使用BeforeXxx\\\\AfterXxx的方式）。例如，可以被取消的结束事件就有Closing事件和Closed事件。   
68.   
69. 长项和常用项的命名  
70.   
71. 　　可使用缩写使名称长度适中，通常，多于 32 个字符的变量名在低分辨率的监视器上难以阅读。同时，请确保缩写在整个应用程序中保持一致。   
72. 　　例如：可以使用“HTML”代替“HyperText Markup Language”。  
73.   
74. 代码书写格式规范  
75.   
76. 文件之中不得存在无规则的空行，比如说连续十个空行。一般来讲函数与函数之间的空行为2\-3行。   
77. 在函数体内部，在逻辑上独立的两个函数块可适当空行，一般为1\-2行。   
78. 每行长度尽量避免超过屏幕宽度，应不超过80个字符。   
79. 尽量用公共过程或子程序去代替重复的功能代码段。   
80. 使用括号清晰地表达算术表达式和逻辑表达式的运算顺序。如将 x=a\*b/c\*d 写成 x=(a\*b/c)\*d可避免阅读者误解为x=(a\*b)/(c\*d)。   
81. 避免采用过于复杂的条件测试。   
82. 避免过多的循环嵌套和条件嵌套。   
83. 一个函数不要超过200行。一个文件应避免超过2000行。   
84. 避免使用**goto**语句。   
85. 避免采用多赋值语句，如x = y = z;。   
86. 代码注释规范  
87.   
88. 　　.cs文件的注释  
89. 　　 所有.cs文件开头都要加上注释，写明文件创建时间、作者、用途概述等  
90. 　　例如：   
91.   
92. //\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
93.   
94. //新增日期:2004.7.19  
95.   
96. //作者:XXX   
97.   
98. //內容说明:　XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  
99.   
100. //\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
101.   
102. 　　函数过程注释  
103. 　　所有的函数体开头都要加上注释，所以注释使用.NET注释规范。  
104. 　　例如：   
105.   
106. /// <summary>  
107.   
108. /// 构造函数  
109.   
110. /// </summary>  
111.   
112. /// <param name='is\_xxx1'>示例参数1</param>  
113.   
114. /// <param name='is\_xxx2'>示例参数2</param>  
115.   
116. **public** UpgradeThread(string is\_xxx1, string is\_xxx2)  
117.   
118. \{  
119.   
120. //…  
121. \}  
122.   
123. 　　常量变量注释  
124. 　　所有的常量变量，无论是全局还是局部使用的，凡是对代码整体起到关键性做用的都需要加上注释。  
125. 　　例如：   
126.   
127. /// <summary>  
128.   
129. /// 当前线程指向的备份文件本地保存路径  
130.   
131. /// </summary>  
132.   
133. **public** string StorePath = '';  
134.   
135. 　　代码修改注释  
136. 　　当开发者维护以前的程序代码时，需要在修改处的开始及结尾，加上自己的注释信息。  
137. 　　例如：   
138.   
139. //BEGIN 2004-7-19 Jayson　修正了XXX问题  
140. 略…  
141. //END 2004-7-19 Jayson