说明详细的net代码规范Word文件下载.docx
- 文档编号:1498990
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:51
- 大小:57.27KB
说明详细的net代码规范Word文件下载.docx
《说明详细的net代码规范Word文件下载.docx》由会员分享,可在线阅读,更多相关《说明详细的net代码规范Word文件下载.docx(51页珍藏版)》请在冰点文库上搜索。
首字母缩写词是由一个短语的首字母组成的,而单词缩写则仅仅把一个单词的长度变短。
要把两个字母的首字母缩写词全部大写,除非他是camelCasing风格的参数名的第一个单词。
System.IO
publicvoidStartIO(StreamioStream)
要把由三个或三个以上字母组成的首字母缩写词的第一个字母大写。
只有第一个字母大写,除非首字母缩写词是camelCasing风格的标识符的第一个单词。
System.Xml
publicvoidProcessHtmlTag(stringhtmlTag)
在涉及大小写时,大多数复合词术语要作为单个单词处理。
不要把所谓闭合形式的复合词中每个单词的首字母大写。
下表列出一些常用的复合词和常用术语的大小写。
表常用的复合词和常用术语的大小写及拼写
Pascal
Not
BitFlag
bitFlag
Bitflag
Callback
callback
CallBack
Canceled
canceled
Cancelled
DoNot
doNot
Dont
dmail
Endpoint
dndpoint
EndPoint
FileName
fileName
Filename
Gridline
gridline
GridLine
Hashtable
hashtable
HashTable
Id
id
ID
Indexes
indexes
Indices
LogOff
logOff
LogOut
LogOn
logOn
LogIn
Metadata
metadata
MetaData,metaData
Multipanel
multipanel
MultiPanel
Multiview
multiview
MultiView
Namespace
namespace
NameSpace
Ok
ok
OK
Pi
pi
PI
Placeholder
placeholder
PlaceHolder
SignIn
signIn
SignOn
SignOut
signOut
SignOff
Sql
sql
SQL
UserName
userName
Username
WhiteSpace
whiteSpace
Whitespace
Writable
writable
Writeable
1.2通用命名约定
通用命名约定讨论的是如何为库元素选择最适当的名称。
这些准则适用于所有标识符。
后面各节讨论特定元素(如命名空间或属性)的命名。
选择名称
1.选择易读的标识符名称。
例如,英文属性名称HorizontalAlignment比AlignmentHorizontal更具可读性。
可读性比简洁性更重要。
属性名称CanScrollHorizontally比ScrollableX(指X轴,但意义不明确)更好。
2.不要使用下划线、连字符或任何其他非字母数字字符。
3.不要使用匈牙利表示法。
匈牙利表示法是在标识符中使用一个前缀对参数的某些元数据进行编码,如标识符的数据类型。
4.避免使用与常用编程语言的关键字冲突的标识符。
虽然符合CLS的语言必须提供将关键字用作普通字的方法,最佳做法不要求强制开发人员了解如何实现。
对于大多数编程语言,语言参考文档都会提供语言所使用的关键字列表。
缩写和首字母缩写词
通常,不应使用缩写或首字母缩写词。
这类名称的可读性较差。
同样,要确定某个首字母缩写词是否已受到广泛认可也是很困难的。
不要将缩写或缩略形式用作标识符名称的组成部分。
例如,使用OnButtonClick而不要使用OnBtnClick。
除非必要,不要使用任何未被广泛接受的首字母缩写词。
语言特定的名称
对于类型名称,应使用语义上有意义的名称而不要使用语言特定的关键字。
例如,名称GetLength比GetInt更好。
在标识符的语义含义仅限于其类型的极少数情况下,应使用一般公共语言运行库(CLR)类型名称,而不要使用语言特定的名称。
例如,将数据转换为Int16的方法应命名为ToInt16而不是ToShort,因为Short是Int16的语言特定的类型名称。
在标识符没有语义含义且参数的类型不重要的极少数情况下,应使用通用名称(如值或项),而不要重复类型名称。
1.3程序集和DLL的命名
大多数情况下,程序集包含全部或部分可重用库,且它包含在单个动态链接库(DLL)中。
一个程序集可拆分到多个DLL中,但这非常少见,在此准则中也没有说明。
程序集和DLL是库的物理组织,而命名空间是逻辑组织,其构成应与程序集的组织无关。
命名空间可以且经常跨越多个程序集。
一定要为程序集DLL选择指示大的功能块(如System.Data)的名称。
程序集和DLL的名称不必对应于命名空间名称,但是在命名程序集时遵循命名空间名称这种做法是合理的。
考虑按下面的模式命名DLL:
<
Company>
.<
Component>
.dll
其中<
包含一个或多个以圆点分隔的子句。
例如,Contoso.WebControls.dll。
1.4名称空间的命名
为命名空间选择的名称应指示命名空间中的类型所提供的功能。
例如,System.Net.Sockets命名空间包含的类型允许开发人员使用套接字通过网络进行通信。
命名空间名称的一般格式如下:
.(<
Product>
|<
Technology>
)[.<
Feature>
][.<
Subnamespace>
]
例如,Microsoft.WindowsMobile.DirectX。
使用公司名称作为命名空间的前缀以防止不同公司开发的命名空间具有相同的名称和前缀。
在命名空间名称的第二级使用稳定的、与版本无关的产品名称。
不要根据组织层次结构确定命名空间层次结构中的名称,因为公司的部门名称经过一段时间后可能会改变。
命名空间名称是长期使用的、不会更改的标识符。
组织的不断发展和变化不应使命名空间名称过时。
使用Pascal大小写格式,并用句点分隔命名空间各部分(如Microsoft.Office.PowerPoint)。
如果您的品牌采用了非传统的大小写,应遵循您的品牌所定义的大小写,即使它与常用的命名空间大小写相背离也如是。
适当的时候可考虑使用复数命名空间名称。
例如,使用System.Collections而不使用System.Collection。
但是,品牌名称和首字母缩写词属于此规则的例外情况。
例如,使用System.IO,而不要使用System.IOs。
命名空间和其中的类型不要使用相同的名称。
例如,不要在将“Debug”用作命名空间名称的同时,又在该命名空间中提供一个名为“Debug”的类。
有些编译器要求对这种类型进行完全限定。
命名空间和类型的名称冲突
如果选择的命名空间或类型的名称与现有名称冲突,则库的用户将不得不对受影响的项的引用进行限定。
在大多数开发情况中,都不应出现这种问题。
本节提供的某些准则适用于下面的命名空间类别:
应用程序模型命名空间
基础结构命名空间
核心命名空间
技术命名空间组
应用程序模型中的命名空间提供特定于应用程序中的某个类的功能集。
例如,System.Windows.Forms命名空间中的类型提供编写Windows窗体客户端应用程序所需的功能。
System.Web命名空间中的类型支持编写基于Web的服务器应用程序。
通常,在同一应用程序中不会使用不同应用程序模型中的命名空间,因此,这降低了名称冲突影响使用您的库的开发人员的可能性。
基础结构应用程序提供专门的支持,很少在程序代码中进行引用。
例如,程序开发工具所使用的*.Designer命名空间中的类型。
*.Permissions命名空间是基础结构命名空间的另一个示例。
与基础结构命名空间中的类型的名称冲突不可能影响使用您的库的开发人员。
核心命名空间是System.*命名空间(不包括应用程序命名空间和基础结构命名空间)。
System和System.Text都是核心命名空间的示例。
应尽可能避免与核心命名空间中的类型发生名称冲突。
属于特定技术的命名空间将具有相同的第一和第二级标识符(Company.technology.*)。
应避免在技术命名空间中出现名称冲突。
命名空间一般准则
不要引入宽泛的类型名称,如Element、Node、Log和Message。
在通常情况下,这样极可能导致类型名称冲突。
应对宽泛的类型名称进行限定(例如FormElement、XmlNodeEventLog、SoapMessage)。
应用程序命名空间准则
不要在单个应用程序模型内为命名空间中的多个类型指定相同的名称。
例如,如果要编写Windows窗体应用程序开发人员要使用的特殊控件库,则不应引入名为Checkbox的类型,因为该应用程序模型已存在同名类型(CheckBox)。
核心命名空间准则
不要指定会与核心命名空间中的任何类型发生冲突的类型名称。
例如,不要使用Directory作为类型名称,因为这会与Directory类型冲突。
技术命名空间准则
不要分配会与单个技术命名空间内的其他类型发生冲突的类型名称。
不要引入会导致技术命名空间的类型与应用程序模型命名空间中的类型发生冲突的类型名称
1.5类、结构和接口的命名
通常,类型名称应该是名词短语,其中名词是由类型表示的实体。
例如,Button、Stack和File都具有名称,用于标识由类型表示的实体。
从开发人员的角度选择标识实体的名称;
名称应反映使用场合。
下面的准则适用于如何选择类型名称。
1.按照Pascal大小写格式,使用名词或名词短语(或偶尔使用形容词短语)为类、接口和值类型命名。
2.不要为类名加前缀(如字母C)。
接口不适用此规则,它应以字母I开头。
3.考虑在派生类的末尾使用基类名称。
例如,从Stream继承的Framework类型以Stream结尾,从Exception继承的类型以Exception结尾。
4.为接口名称加上字母I前缀,以指示该类型为接口。
5.在定义类/接口对(其中类是接口的标准实现)时,一定要确保类和接口的名称除接口名称以字母I为前缀外,二者应完全相同。
例如,Framework提供IAsyncResult接口和AsyncResult类。
1.5.1泛型类型参数命名
要用描述性的名字来命名泛型类型参数,除非一个字母就足够了,而且描述性的名字并不能增加什么价值。
publicinterfaceIsessionChannel<
TSession>
{...}
publicdelegateToutputConverter<
Tinput,TOutput>
(Tinputfrom)
publicclassList<
T>
考虑用T来命名参数类型,如果类型只有一个类型参数,且类型参数只有一个字母。
publicintIcomparare<
{...}
publicdelegateboolPredicate<
(Titem);
publicstructNullable<
whereT:
struct{...}
要给描述性的类型参数名加上T前缀
whereTsession;
考虑在类型参数名中显示出施加于该类型参数上的限制。
例如,可以把一个被限定为ISession的类型参数命名为Tsession。
1.5.2常用类型命名
表派生自或实现某些特点的核心类型的命名规则
基类
派生类型/实现类型的规范
System.Attribute
要给自定义的Atrribute类添加“Attribute”后缀。
System.Delegate
要给用于事件处理的委托添加“EventHandler”后缀。
要给用于事件处理之外的那些委托添加“Callback”后缀。
不要给委托添加“Delegate”后缀。
System.EventArgs
要添加“EventArgs”后缀。
System.Enum
不要派生自该类;
要用编程语言的提供的关键字来代替。
例如在C#中,要用enum关键字。
不要添加“Enum”或“Flag”后缀。
System.Exception
要添加“Exception”后缀。
System.Collections.IDictionary
要添加“Dictionary”后缀。
System.Collections.Generic.IDictionary<
TKey,TValue>
System.Collections.IEnumerable
要添加“Collection”后缀。
System.Collections.ICollection
System.Collections.IList
System.Collections.Generic.ICollection<
System.Collections.Generic.IList<
System.IO.Stream
要添加“Stream”后缀。
System.Security.CodeAccessPermission
要添加“Permission”后缀。
System.Security.IPermission
1.5.3枚举的名称
不要在枚举值名称中使用前缀。
例如,不要对ADO枚举使用ad之类的前缀,也不要对多格式文本枚举使用rtf之类的前缀,依此类推。
这还意味着不应在枚举值名称中包含枚举类型名称。
下面的代码示例演示了不正确的枚举值命名。
publicenumTeams
{
TeamsAlpha,
TeamsBeta,
TeamsDelta
}
不要将Enum用作枚举类型的后缀。
不要在标志枚举的名称中添加Flags作为后缀。
对枚举使用单数名称,除非枚举值是位域。
对使用位域值的枚举(也称为标志枚举)使用复数名称。
1.6类型成员的命名
1.6.1方法的命名
要用动词或动词词组来命名方法。
publicclassString{
publicintCompareTo(...);
publicstring[]Split(...);
publicstringTrim();
1.6.2属性的命名
要用名词、名词词组或形容词来命名属性。
publicclassString{
publicintLength{get;
不要让属性名看起来与“GET”方法的名字相似,如下面的例子所示。
publicstringTextWriter{get{...}set{...}}
publicstringGetTextWriter(intvalue){...}
要用肯定性的短语(CanSeek而不是CantSeek)来命名布尔属性。
如果有帮助,还可以有选择性地给布尔属性添加“Is”、“Can”或“Has”等前缀。
例如,CanRead要比Readable更容易理解,但Created却比IsCreated的可读性更好。
前缀通常是多余的,也没有必要,尤其是在有Intellisense的代码编辑器中。
输入MyObject.Enabled=与输入MyObject.IsEnabled=一样清楚,两种情况下Intellisense都会提示你选择true或false,但后者更为冗长一些。
考虑用属性的类型名来命名属性。
例如,下面这个属性的作用是取得和设置一个名为Color的枚举值,因些它被命名为Colors:
publicenumColor{...}
publicclassControl{
publicColorColor{get{...}set{...}}
1.6.3事件的命名
要用动词或动词短语来命名事件。
这样的例子包括Clicked、Painting、DroppedDown等等。
要用现在时和过去时来赋予事件名以之前和之后的概念。
例如,在窗口关闭之前发生的close事件应该命名为Closing,而在窗口关闭之后发生的应该命名为Closed。
不要用“Before”和“ After”前缀或后缀来区分前置事件和后置事件。
要在命名事件处理函数(用作事件类型的委托)时加上“EventHandler”后缀,如下面的例子所示:
publicdelegatevoidClickedEventHandler(objectsender,clickedEventArgse);
要在事件处理函数中用sender和e作为两个参数的名字。
参数sender表示触发该事件的对象。
虽然参数sender可以是一个更为具体的类型,但一般来说其类型就是object。
整个.NET框架一致地使用了这种模式。
publicdelegatevoid<
EventName>
EventHandler(objectsender,<
EventArgse);
要在命名事件的参数类时加上“EventArgs”后缀,如下面的例子所示:
publicclassClickedEventArgs:
EventArgs{
intx;
inty;
publicClickedEventArgs(intx,inty){
this.x=x;
this.y=y;
}
publicintx{get{returnx;
}}
publicinty{get{returny;
}}
1.6.4字段的命名
要在命名字段时使用PascalCasing大小写风格。
publicstaticreadonlystringEmpty;
要用名词或名词短语来命名字段。
不要给字段名添加前缀。
例如,不要用“g_”或“s_”来区分静态和非静态字段。
1.7参数的命名
要在命名参数时使用camelCasing大小写风格。
publicboolContains(stringvalue);
publicstringRemove(intstartIndex,intcount);
要使用具有描述性的参数名。
参数名应该具备足够的描述性,使用在大多数情况下,用户根据参数的名字和类型就能够确定它的意思。
考虑根据参数的意思而不是参数的类型来命名参数。
开发工具必须向用户提供关于类型的有用信息,这样用户就能更好地利用参数名来描述语义,而不是描述类型。
偶尔使用基于类型的参数名是完全可以的,但在采用这些规范时再回到匈牙利命名法则是绝对不应该的。
1.8资源的命名
要在命名资源关键字(resourcekey)时使用PascalCasing大小写风格。
要使标识符的名字具有描述性而不是使名字变短。
应该尽可能地使名字简短,但前提是不能牺牲可读性。
不要使用各主要CLR编程语言特有的关键字。
要在命名资源时仅使用字母、数字和下划线。
要用点号来给标识符清楚地划分层次。
例如,如果要设计菜单系统的资源,那么可以考虑按下面的方式来命名它们:
Menus.FileMenu.Close.Text
Menus.FileMenu.Close.Color
Menus.FileMenu.SaveAs.Text
Menus.FileMenu.About.Text
要在为异常的消息资源命名时遵循下面的命名约定。
资源标识符应该是异常的类型名加上一个简短的异常标识符,之间以点号分隔:
ArgumentException.IllegalCharacters
ArgumentException.InvalidName
ArgumentException.FileNameIsMalformed
2类型设计规范
要确保每个类型由一组定义明确、相互关联的成员组成,而不仅仅是一些无关功能的随机集合。
能用简单的一句话来描述一个类型是非常重要的。
一个好的定义应该还能去除那些不怎么有关的功能。
2.1类型和名称空间
要用名称空间把类型组织成一个相关的特性域的层次结构。
该层次结构应该为开发人员更容易地浏览框架并找到想要的API而优化。
避免非常深的名称空间层次。
这样的层次难于浏览,因为用户不得不经常地回溯。
避免有太多的名称空间。
在最常见的场景中,框架的用户应该不需要导入许多的名称空间。
只要有可能,就应该把常见场景中一起使用的类型放在一个单独的名称空间中。
避免把为高级场景而设计的类型和为常见编程任务而设计的类型放在同一个名称空间中。
这使得用户不仅能更容易地理解框架的基本概念,而且能更容易地在常见的场景中使用框架。
不要不指定名称空间就定义类型。
这把相关的类型组织到一个层次结构中,而且有助于解决可能存在的名字冲突。
请注意名称空间有助于解决名字冲突的事实并不意味着应该引入这样的冲突。
标准子名称空间的命名
1、.Desi
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 说明 详细 net 代码 规范
![提示](https://static.bingdoc.com/images/bang_tan.gif)