C#代码规范 .NET程序员需要提升的修养

一、  环境设置 

首先去除VS开发环境中的一些选项如下:

粘贴时调整缩进

将类型的左大括号置于新行

将方法的左大括号置于新行

将匿名方法的左大括号置于新行

将控制块的左大括号置于新行

将“else”置于新行

将“catch”置于新行

将“finally”置于新行

复选框去掉.

 

二、  命名规范

1)        通用性

l   标识的总长度不要超过32个字符。

l     标识符的基本语法是以字母和_开始,由字母数字及下划线组成的单词,第一个字符不能是数字。

l     只要合适,在变量名的末尾追加计算限定符(Avg、Sum、Min、Max、Index)。

l     在变量名中使用互补对,如 min/max、begin/end 和 open/close。

l     布尔变量名应该前加或包含 Is(is)。

l   尽量减少使用缩写,而是使用以一致方式创建的缩写。缩写应该只有一个意思;同样,每个缩写词也应该只有一个缩写。例如,如果用 min 作为 minimum 的缩写,那么在所有地方都应这样做;不要将 min 又用作 minute 的缩写。

l   在命名函数时包括返回值的说明,如 GetCurrentWindowName()。

l   避免对不同的元素重用名称,如名为 ProcessSales() 的例程和名为 iProcessSales 的变量。

l   在命名元素时避免同音异义词(如 write 和 right),以防在检查代码时发生混淆。

l   在命名元素时,避免使用普遍拼错的词。另外,应清楚区域拼写之间存在的差异,如 color/colour 和 check/cheque。

l   在内部范围中避免使用与外部范围中的名称相同的名称。若访问错误变量,则会产生错误结果。若变量与同一名称的关键字冲突,则必须在关键字前加适当的类型库以作标识。例如,若有一个名为 date 的变量,只能通过调用 System.Date 来使用内部 Date 函数。

l   接口名称以前缀“I”开始,后面接一个名词或名词词组(如 IComponent),或者接一个描述接口行为的形容词(如 IPersistable)。不要使用下划线,不要过多使用缩写,因为缩写会引起混淆。

l   事件处理程序的名称以一个描述事件类型的名词开始,后面接后缀“EventHandler”,如“MouseEventHandler”。 事件参数类的名称里要加“EventArgs”后缀。

l   如果某事件含有“之前”或“之后”的概念,请以现在时或过去时形式使用前缀,如“ControlAdd”或“ControlAdded”。

l   单个长字符串拆分成多行写。当一行被分为几行时,需要将串联运算符放在每一行的末尾。

l   SQL Server中不要给存储过程加sp 前缀/不要给用户定义的函数加 fn_ 前缀/不要给扩展存储过程加 xp_ 前缀。这些前缀是为标识系统保留的。将每个主要的SQL子句放在不同的行上,这样更容易阅读和编辑语句。

l   不要使用原义数字或原义字符串,如 For i = 1 To 7。而是使用命名常数,如 For i = 1 To NUM_DAYS_IN_WEEK 以便于维护和理解。

2)        变量命名

变量名称命名规则:形容词+名词(或名词)

  1. 属性(类属性/类属性对应的私有变量)

l  类属性与类属性对应的私有变量基本一样。

类属性对应的私有变量是在类属性名的前面加“_”

如:private int _PageSize;// 类属性对应的私有变量

public int PageSize { set { _PageSize = value; } }//类属性

l  注意大小写要保持一致。每个单词的第一个字母必须大写。其它单词的第一个字母也大写。单词之间不加“_”。

l  不要使用public来定义一个属性。

l  属性名和类名以名词开始,如 EmployeeName 和 CarAccessory。

  1. 私有变量(短期性/长期性)

l  短期性(方法内私有变量/不是经常用的变量)

u  定义前加“_”

u  如:string _strSQL = null;

u  第一个单词的第一个字母必须小写,其它单词第一个字母大写。单词之间不加“_”。

l  长期性(类私有变量/方法入口参数)

u  类私有变量:前加“_”,和类属性对应的私有变量一样。每个单词的第一个字母必须大写。其它单词的第一个字母也大写。单词之间不加“_”。

如:private int _PageSizeTmp;

u  方法入口参数:第一个单词的第一个字母必须小写,其它单词的第一个字母必须大写。如果只有一个单词组成全小写。单词之间不加“_”。

如:public static int SendCTTVOSMS(string mobile,string content)

public static string CallAccountHiVA(string restPhone,string userPhone)

  1. 全局变量/静态变量/常量

l  定义要全部大写。如:public static int SMS_TYPE = 2;

l  定义部分也可小写。

如:public static string VOSMS_UserName = "88000002";

l  单词与单词之间加“_”分隔。

3)        函数命名

函数命名规则:动词+名词(或动词),每个单词第一个字母必须大写。单词之间不加“_”。

如:public static string GetOrderStatus(int sendMode,int statueID)

函数名和方法名以动词开始,如 InitNameArray() 和 CloseDialog()。

4)        控件命名

控件命名规则:类别+名称

类别对照表:

前缀

表示类型

frm

窗口

btn

按钮

cbo

下拉式列表框

txt

文本输入框

lbl

标签

img

图像

pic

图片

div

DIV

grd

网格

scr

滚动条

lst

列表框

sds

SqlDataSource

ods

OleDbDataSource

如按钮:btnSave

 

前缀

表示类型

b/is

Bool

c

Char

sb

Sbyte

b

Byte

n/i

Int

ui

Uint

l

Long

ul

Ulong

f

Float

d

Double

s/str

String

 

5)        表字段命名

l   在命名表时,用单数形式表示名称。例如,使用 Employee,而不是 Employees。

l   在命名表的列时,不要重复表的名称;例如,在名为 Employee 的表中避免使用名为 EmployeeLastName 的字段。

l   不要在列的名称中包含数据类型。如果后来有必要更改数据类型,这将减少工作量。

6)        Web文件目录结构命名

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

l   Web文件第一个单词的首字符要小写其它单词的首字符要大写。或全小写。文件存在后,在程序中要严格按照文件的大小写引入文件。目录名称必须全小写。

l   Web目录结构:

根---类库1

类库…N

解决方案启动文件

项目发布目录

    Web源代码--- inc( JS目录)

css(CSS目录)

后台目录

bin目录

app_data数据库目录

master目录

其它子功能目录

app_code类文件

images图片目录

 

三、  注释规范

1)        在文件的头部标明文件的作者,完成时间,它所完成的主要功能。

2)        程序有过改动后,要写上修改人、时间、简单原因说明列表。

如:

/********************************************************************

* 谁创建的 日期 什么功能描述

* 谁修改的 日期 什么功能描述

* 谁修添加 日期 什么功能描述

* 谁修删除 日期 什么功能描述

********************************************************************/

 

3)        函数等代码中的注释规范都按系统自动的注释格式

4)        修改代码时,总是使代码周围的注释保持最新。

5)        在每个例程的开始,提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍。

6)        避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时,行尾注释是合适的;在这种情况下,将所有行尾注释在公共制表位处对齐。

7)        避免杂乱的注释,如一整行星号。

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

9)        如果需要用注释来解释复杂的代码节,请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码,而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能,但必须保持性能和可维护性之间的平衡。

10)    在编写注释时使用完整的句子。注释应该阐明代码,而不应该增加多义性。

11)    在编写代码时就注释,因为以后很可能没有时间这样做。另外,如果有机会复查已编写的代码,在今天看来很明显的东西六周以后或许就不明显了。

12)    避免多余的或不适当的注释,如幽默的不主要的备注。

13)    使用注释来解释代码的意图。它们不应作为代码的联机翻译。

14)    注释代码中不十分明显的任何内容。

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

16)    对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。

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

18)     用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时,这样做会使注释很明显且容易被找到。

19)     为了防止在阅读代码时左右滚动源代码编辑器,每行代码或注释不得超过一个显示屏。

20)     可能多的注释变量表示的意思。

四、  其它代码风格/习惯

1)        JS和CSS文件必需是UTF-8编码的文件。

2)        单行的判断代码不需要加“{}”。

如:if (_url.Trim().Equals(String.Empty)) return -2;

能简写的代码要简写。保证自己写出来的代码每一句都是有效代码。

3)        不要使用VS的自动排版代码功能。

4)        少用“==”运算。应该使用“.Equals”进行比较。

5)        运算符前后要空一格。如:_TotalPage = _TotalRecord / _PageSize; 这样做是不会改变代码意图的,却可以使代码更加容易阅读。

6)        每一个操作结束后加一个空行。所有代码里不能有连续的二个或二个以上的空行。

7)        将大的复杂代码节分为较小的、易于理解的模块。

8)        近可能的使用TAB键来空位。不要使用4个空格来代替TAB键。

9)        在页面文件中不能定义static类型的来传递数据。

10)     

 

posted @ 2015-11-23 13:18  少时不知贵  阅读(232)  评论(0编辑  收藏  举报