C#Net编程规约.docx

C#Net编程规约.docx

《C#Net编程规约.docx》由会员分享，可在线阅读，更多相关《C#Net编程规约.docx（22页珍藏版）》请在冰豆网上搜索。

C#Net编程规约

C#.Net编程规约

1概述

1.1规范制定原则

1方便代码的交流和维护。

2不影响编码的效率，不与大众习惯冲突。

3使代码更美观、阅读更方便。

4使代码的逻辑更清晰、更易于理解。

1.2术语定义

1.2.1Pascal大小写

Pascal大小写形式是指名称中单词的第一个字母大写，如：

EmployeeSalary,ConfirmDialog。

1.2.2Camel大小写

这种形式类似于Pascal大小写形式，但名称中第一个单词的第一个字母不是大写：

employeeSalary,comfirmDialog。

2命名

对于理解应用程序的逻辑流，命名方案是最有影响力的一种帮助。

名称应该说明“什么”而不是“如何”。

通过避免使用公开基础实现（它们会发生改变）的名称，可以保留简化复杂性的抽象层。

例如，可以使用GetNextStudent（），而不是GetNextArrayElement（）。

2.1命名原则

选择正确名称时的困难可能表明需要进一步分析或定义项的目的。

使名称足够长以便有一定的意义，并且足够短以避免冗长。

唯一名称在编程上仅用于将各项区分开。

表现力强的名称是为了帮助人们阅读；因此，提供人们可以理解的名称是有意义的。

不过，请确保选择的名称符合适用语言的规则和标准。

最好不要使用带有下划线的单词。

使用全称避免缩写，除非缩写已是一种公认的约定，如URL、HTML。

2.2命名大小写原则

在名称的大小写方面，名称大部分都应采用Pascal大小写命名形式。

其中，命名空间、类、以及基类中的成员、接口、属性、方法、事件、静态字段等的名称都应遵循该规则。

对于常量的定义采用全部大写的原则。

此外还推荐使用另一种大小写模式：

camel大小写形式。

有两种情况建议使用camel大小写形式。

1传递给方法的所有参数都应是camel大小写形式：

PublicvoidRecordSale（intemployeeSalary,intquanitity）;

2camel大小写形式也可以用于区分同名的两个对象—比较常见的情况是属性封装一个字段：

PrivatestringemployeeName;

PublicstringEmployeeName

{

Get

{

ReturnemployeeName;

}

}

2.3命名空间

命名空间（namespace）的名称非常重要，需要仔细设计，以避免一个命名空间中对象的名称与其他对象同名。

命名空间的名称是.Net区分共享装配件中对象名的唯一方式，如果软件包的命名空间使用的名称与另一个软件包相同，而这两个软件包都安装到一台计算机上，就会出问题。

因此，命名空间的名称最好用本公司名创建顶级的命名空间，再嵌套客户所在公司、或产品类所在软件包的命名空间,继而嵌套软件中所在模块层次名字的命名空间。

例如Pcguandian，DataAccess。

这样的命名空间就肯定是安全的，不会与其他人编写的命名空间同名。

2.4变量

2.4.1变量前缀

C#的约定是命名变量时不使用任何前缀：

stringResult;stringMessage。

2.4.2杂项

a）在变量名中使用互补对，如min/max、begin/end和open/close

b）布尔变量名应该包含Is，这意味着Yes/No或True/False值，如fileIsFound

c）即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。

仅对于短循环索引使用单字母变量名，如i或j

d）不要使用原义数字或原义字符串，如Fori=1To7。

而是使用命名常数，如Fori=1ToNUM_DAYS_IN_WEEK以便于维护和理解

2.5控件

2.5.1命名方法

和社内其他编程工具开发规约类似，控件命名采用控件名简写+英文描述的方式，其中英文描述首字母大写

2.5.2主要控件名简写对照表

控件名简写

Labellbl

TextBoxtxt

Buttonbtn

LinkButtonlnkbtn

ImageButtonimgbtn

DropDownListddl

ListBoxlst

DataGriddg

DataListdl

CheckBoxchk

CheckBoxListchkls

RadioButtonrdo

RadioButtonListrdolt

Imageimg

Panelpnl

Calendercld

AdRotatorar

Tabletbl

RequiredFieldValidatorrfv

CompareValidatorcv

RangeValidatorrv

RegularExpressionValidatorrev

ValidatorSummaryvs

CrystalReportViewerrptvew

2.6类

a）用名词或名词短语命名类似

b）不要使用类型前缀，如在类名称上对类使用C前缀。

例如，使用类名称FileStream，而不是

CFileStream

c）有时候需要提供以字母I开始的类名称，虽然该类不是接口。

只要I是作为类名称组成部分的整个单词的第一个字母，这便是适当的。

例如，类名称IdentityStore是适当的。

在适当的地方，使用复合单词命名派生的类。

派生类名称的第二个部分应当是基类的名称。

例如，ApplicationException对于从名为Exception的类派生的类是适当的名称，原因ApplicationException是一种Exception

2.7接口

a）用名词或名词短语，或者描述行为的形容词命名接口。

例如，接口名称IComponent使用描述性

名词。

接口名称ICustomAttributeProvider使用名词短语。

名称IPersistable使用形容词。

b）给接口名称加上字母I前缀，以指示该类型为接口。

在定义类/接口对（其中类是接口的标准实现）时使用相似的名称。

两个名称的区别应该只是接口名称上有字母I前缀。

以下是正确命名的接口的示例。

publicinterfaceIServiceProvider

publicinterfaceIFormatable

以下代码示例阐释如何定义IComponent接口及其标准实现Component类。

publicinterfaceIComponent

{

//Implementationcodegoeshere.

}

publicclassComponent:

IComponent

{

//Implementationcodegoeshere.

}

2.8属性（Attribute）

应该总是将后缀Attribute添加到自定义属性类。

以下是正确命名的属性类的示例。

publicclassObsoleteAttribute

{

}

2.9枚举（Enum）

a）不要在Enum类型名称上使用Enum后缀。

b）对大多数Enum类型使用单数名称，但是对作为位域的Enum类型使用复数名称。

c）总是将FlagsAttribute添加到位域Enum类型。

2.10方法

使用动词或动词短语命名方法。

以下是正确命名的方法的实例

RemoveAll（）

GetCharArray（）

Dispose（）

2.11属性（Property）

a）使用名词或名词短语命名属性。

b）不要使用匈牙利语表示法。

c）考虑用与属性的基础类型相同的名称创建属性。

例如，如果声明名为Color的属性，则属性的类型同样应该是Color。

请参阅后面的示例。

以下代码示例阐释提供其名称与类型相同的属性。

publicenumColor

{

//InsertcodeforEnumhere.

}

publicclassControl

{

publicColorColor

{

get

{

//Insertcodehere.

}

set

{

//Insertcodehere.

}

}

}

以下代码示例不正确，原因是Color属性是Integer类型的。

publicenumColor

{

//InsertcodeforEnumhere.

}

publicclassControl

{

publicintColor

{

//Insertcodehere

}

}

在不正确的示例中，不可能引用Color枚举的成员。

Color.Xxx将被解释为访问一个成员，该

成员首先获取Color属性（C#中为int类型）的值，然后再访问该值的某个成员（该成员

必须是System.Int32的实例成员）

2.12事件

a）对事件处理程序名称使用EventHandler后缀。

b）指定两个名为sender和e的参数。

sender参数表示引发事件的对象。

sender参数始终是object类型的，即使在可以使用更为特定的类型时也如此。

与事件相关联的状态封装在名为e的事件类的实例中。

对e参数类型使用适当而特定的事件类。

c）用EventArgs后缀命名事件参数类。

d）考虑用动词命名事件。

e）使用动名词（动词的“ing”形式）创建表示事件前的概念的事件名称，用过去式表示事件后。

例如，可以取消的Close事件应当具有Closing事件和Closed事件。

不要使用BeforeXxx/AfterXxx命名模式。

f）不要在类型的事件声明上使用前缀或者后缀。

例如，使用Close，而不要使用OnClose。

g）通常情况下，对于可以在派生类中重写的事件，应在类型上提供一个受保护的方法（称为OnXxx）。

此方法只应具有事件参数e，因为发送方总是类型的实例。

以下示例阐释具有适当名称和参数的事件处理程序。

publicdelegatevoidMouseEventHandler（objectsender,MouseEventArgse）;

以下示例阐释正确命名的事件参数类。

publicclassMouseEventArgs:

EventArgs

{

intx;

inty;

publicMouseEventArgs（intx,inty）

{

this.x=x;

this.y=y;

}

publicintX

{

get

{

returnx;

}

}

publicintY

{

get

{

returny;

}

}

}

2.13集合

集合是一组组合在一起的类似的类型化对象，如哈希表、查询、堆栈、字典和列表，集合的命名

建议用复数。

2.14表

a）在命名表时，用单数形式表示名称。

例如，使用Employee，而不是Employees

b）在命名表的列时，不要重复表的名称；例如，在名为Employee的表中避免使用名为EmployeeLastName的字段

c）不要在列的名称中包含数据类型。

如果后来有必要更改数据类型，这将减少工作量

2.15杂项

a）尽量减少使用缩写，而是使用以一致方式创建的缩写。

缩写应该只有一个意思；同样，每个缩写

词也应该只有一个缩写。

例如，如果用min作为minimum的缩写，那么在所有地方都应这样

做；不要将min又用作minute的缩写。

b）在命名函数时包括返回值的说明，如GetCurrentWindowName（）。

c）与过程名一样，文件和文件夹的名称也应该精确地说明它们的用途。

\

2.16措词

避免使用与常用的.NET框架命名空间重复的类名称。

例如，不要将以下任何名称用作类名称：

System、Collections、Forms或UI。

有关.NET框架命名空间的列表，请参阅类库。

另外，避免使用和以下关键字冲突的标识符。

AddHandler

AddressOf

Alias

And

Ansi

As

Assembly

Auto

Base

Boolean

ByRef

Byte

ByVal

Call

Case

Catch

CBool

CByte

Cchar

CDate

CDec

CDbl

Char

Cint

Class

CLng

CObj

Const

Cshort

CSng

CStr

CType

Date

Decimal

Declare

Default

Delegate

Dim

Do

Double

Each

Else

ElseIf

End

Enum

Erase

Error

Event

Exit

ExternalSource

False

Finalize

Finally

Float

For

Friend

Function

Get

GetType

Goto

Handles

If

Implements

Imports

In

Inherits

Integer

Interface

Is

Let

Lib

Like

Long

Loop

Me

Mod

Module

MustInherit

MustOverride

MyBase

MyClass

Namespace

New

Next

Not

Nothing

NotInheritable

NotOverridable

Object

On

Option

Optional

Or

Overloads

Overridable

Overrides

ParamArray

Preserve

Private

Property

Protected

Public

RaiseEvent

ReadOnly

ReDim

Region

REM

RemoveHandler

Resume

Return

Select

Set

Shadows

Shared

Short

Single

Static

Step

Stop

String

Structure

Sub

SyncLock

Then

Throw

To

True

Try

TypeOf

Unicode

Until

volatile

When

While

With

WithEvents

WriteOnly

Xor

Eval

extends

instanceof

package

var

3注释

3.1注释概述

a）修改代码时，总是使代码周围的注释保持最新。

b）在每个例程的开始，提供标准的注释样本以指示例程的用途、假设和限制很有帮助。

注释样本应该是解释它为什么存在和可以做什么的简短介绍。

c）避免在代码行的末尾添加注释；行尾注释使代码更难阅读。

不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释在公共制表位处对齐。

d）避免杂乱的注释，如一整行星号。

而是应该使用空白将注释同代码分开。

e）避免在块注释的周围加上印刷框。

这样看起来可能很漂亮，但是难于维护。

f）在部署发布之前，移除所有临时或无关的注释，以避免在日后的维护工作中产生混乱。

g）在编写注释时使用完整的句子。

注释应该阐明代码，而不应该增加多义性。

h）在编写代码时就注释，因为以后很可能没有时间这样做。

另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。

i）为了防止问题反复出现，对错误修复和解决方法代码总是使用注释，尤其是在团队环境中。

j）对由循环和逻辑分支组成的代码使用注释。

这些是帮助源代码读者的主要方面。

k）在整个应用程序中，使用具有一致的标点和结构的统一样式来构造注释。

l）用空白将注释同注释分隔符分开。

在没有颜色提示的情况下查看注释时，这样做会使注释很明显且容易被找到。

m）在所有的代码修改处加上修改标识的注释。

n）为了使层次清晰，在闭合的右花括号后注释该闭合所对应的起点。

如：

namespaceCCC.DataAccess

{

publicclassDepts:

IDisposable

{

//

//classcode;

//

}//classDepts

}//namespaceCCC.DataAccess

3.2文件注释

每个模块文件（.cs文件）都应有一个注释标头，包含创建信息和每次修改信息、版权信息等内容，如：

//----------------------------------------------------------------

//Copyright（C）2004-2005

//Allrightsreserved.

//

//CreateDate:

2005/05/29

//CreateMan:

//

//ModifyHistory:

//ModifyDate:

2005/06/19

//ModifyMan:

//ModifyDesc:

//ModifyDate:

2005/06/29

//ModifyMan:

//ModifyDesc:

//----------------------------------------------------------------

3.3类的注释

对每个类的注释要求在