C# 开发代码标准

开发标准文件

文件名称:C#开发规范

版 本:V2.0

前言

目的是为了规范每个人的编程风格,为确保系统源程序可读性,从而增强系统可维护性,制定下述编程规范,以规范系统各部分编程。系统继承的其它资源中的源程序也应按此规范作相应修改。

规则: 编程时强制必须遵守的原则。建议: 编程时必须加以考虑的原则。格式: 对此规范格式的说明。说明: 对此规范或建议进行必要的解释。示例: 对此规范或建议从正、反两个方面给出例子。

内容包括:排版、命名规则、基本原则、注释、表达式与语句、类与接口, JavaScript 编码过程的排版、命名、声明、注释等等。 自标准公布日起,所有代码都要遵守本标准。在系统的编码、测试及维护过程中,要求严格遵守。

规范制定原则

1.1方便代码的交流和维护

说明:这是编码基础,贯穿整个软件生命周期,只有易读、易维护方便后期软件维护升级,这样的代码才有生命持久力。

1.2使代码更美观、阅读更方便

说明:保持代码的简洁化是软件工程化的基本要求。除非是底层封闭性开发,否则代码苦涩难懂,就会造成封闭。

1.3编程时要达到正确性,及性能高效性

说明:编程考虑正确性、可维护性、可扩展性等质量因素,性能考虑要放在重要位置,因为性能时常会影响到正确及可维护。

1.4需求、变更标准规范可以减少同样的错误出现

说明:需求,变更标准规范,可以让我们减少错误出现的频率。(暂时需求文档还未编写)

程序排版

程序排版的目的是使代码的逻辑更清晰、更易于理解,不仅可以确保系统源程序可读性,而且会涉及到产品质量,涉及到个人能力的提高。

代码外观

2.1.1【规则】源代码的排版顺序

顺序是:using语句、命名空间、注释、类。

说明:以下内容如果某些节不需要,可以忽略。但是其它节要保持该次序。

正例:

using System;
				namespace HyBy.xxx
				{
				   /// <summary>
				   /// 版权所有: 版权所有(C) 2013,华跃博弈
				   /// 内容摘要: 本类是…..,包括主要……模块、……函数及功能是…….
				   /// 完成日期: 输入完成日期,例:2013-9-1
				   /// 版    本:
				   /// 作    者:
				   ///
				   /// 修改记录1: 修改历史记录,包括修改日期、修改者及修改内容
				   /// 修改日期:
				   /// 版 本 号:
				   /// 修 改 人:
				   /// 修改内容:
				   /// 修改记录2: …
				   /// </summary>
				   public class Test
				   {

				   }
				}

2.1.2 【规则】按照统一的顺序来书写using语句

不同类别的using语句之间用空行分隔。

说明: using 中标准的命名空间要在本地的命名空间之前,注意按照字母顺序排列。

正例:


				using System;	// .Net的
				using System.Data;
				using OverFlow.Win.Wps;	//第三方的
				using HyBy.HyB;	//程序自身的
											

2.1.3 【规则】分界符

说明:(如大括号‘{’和‘}’)应各独占一行并且位于同一列,同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switZH、case 语句中的程序都要采用如上的缩进方式

反例:


				for (...) {
				... // 程序代码
				}
				if (...)
				{
				... // 程序代码
				}
				void example_fun( void )
				{
				... // 程序代码
				}
											

正例:


				for (...)
				{
				... // 程序代码
				}
				if (...)
				{
				... // 程序代码
				}
				void example_fun( void )
				{
				... // 程序代码
				}
											

2.1.4 【规则】程序中一行的代码和注释不能超过80列。

说明:包括空格在内不超过80列。

尽量代码列宽控制在屏幕宽度以内左右,每行长度尽量避免超过屏幕宽度。

2.1.5 【规则】条件语句处理

if、else、else if、for、while、do等,执行语句换行。必须加{}。

说明:这样可以防止书写失误,也易于阅读。

反例:


				if (varible1 < varible2) varible1 = varible2;
											

正例:


				if(varible1 < varible2)
				{
				varible1 = varible2;
				}
											

2.1.6 〖建议〗源代码中关系较为紧密的代码应尽可能相邻。

说明:这样便于程序阅读和查找。

正例:


				iLength	= 10;
				iWidth		= 5; // 矩形的长与宽关系较密切,放在一起。
				StrCaption	= “Test”;
											

反例:


				iLength	= 10;
				strCaption	= “Test”;
				iWidth		= 5;
											

对齐

2.2.1 【规则】使用TAB键缩进

缩进应该是每行一个Tab(4个空格的距离),不要在代码中使用Tab字符。

说明:消除不同编辑器对TAB处理的差异,有的代码编辑器可以设置用空格代替TAB键。

2.2.2 【规则】程序的分界符‘{’和‘}’

左花括号 “{”放于关键字或方法名的下一行并与之对齐。{ }之内的代码块使用缩进规则对齐。

说明:这样使代码便于阅读,并且方便注释。

do while语句和结构的类型化时可以例外,while条件和结构名可与 } 在同一行。

正例:


				void Function(int iVar)
				{                       // 独占一行并与引用语句左对齐。
				while (condition)
				{
				TestSomething();   // 与{ }缩进4格
				}
				}
											

反例:


				void Function(int iVar){
				while (condition){
				TestSomething();
				}}
											

2.2.3 【规则】相关的赋值语句等号对齐。

正例:


				tERPTes.wHead		= 0;
				tERPTes.wTail		= wMaxNumOfERP - 1;
				tERPTes.wFree		=wMaxNumOfERP;
				tERPTes.wAddress	=  wERPAddr;
				tERPTes.wSize		= wERPSize;
											

空行空格

2.3.1 【规则】空行。

说明:空行是为了将逻辑上相关联的代码分块,以便提高代码的可阅读性。

正例:


				voidSpy(void)
				{
				// Spy实现代码
				}
				// 空一行
				voidLbck(void)
				{
				// Ack实现代码
				}
											

反例:


				voidSpy(void)
				{
				// Hey实现代码
				}
				voidLbck (void)
				{
				// Lbck实现代码
				}
				//两个逻辑程序块,用空行加以分隔。
											

2.3.2 【规则】一元操作符

一元操作符、++及--与操作数间不需要空格。“[]”、“.”这类操作符前后不加空格。

正例:


				!bValue
				~iValue
				++iCount
				&fSum
				aiNumber[i]= 5;
				tBox.dWidth
											

2.3.3 【规则】多元运算符和它们的操作数之间至少需要一个空格。

正例:


				iNumberA  +=iNumberB  +iNumberC;
											

2.3.4 【规则】关键字和左括符 “(” 应该用空格隔开

说明:if、for、while等关键字之后应留一个空格再跟左括号‘(’,以突出关键字。

正例:在方法名和左括符 “(” 之间不要使用空格,这样有助于辨认代码中的方法调用与关键字。


				while凵(true)
											

2.3.5 【规则】函数名之后不要留空格。

说明:函数名后紧跟左括号‘(’,以与关键字区别。

2.3.6 【规则】空格处理

‘(’向后紧跟,‘)’、‘,’、‘;’向前紧跟,紧跟处不留空格。‘,’之后要留空格。‘;’不是行结束符号时其后要留空格。

正例:


				for (i = 0; i < MAX_BSC_NUM; i++)
				{
				TestSomething(iWidth,凵iHeight);
				}
											

2.3.7 【规则】注释符与注释内容之间要用一个空格进行分隔。

正例:


				/* 注释内容 */
				// 注释内容
											

反例:


				/*注释内容*/
				//注释内容
											

换行

2.4.1 【规则】长表达式。

(超过120列)要在低优先级操作符处换行,换行注意要与第一个条件对齐。

说明:

1、在逗号后换行。

2、在低优先级操作符前换行。

3、1优先2

正例:


				if ((iFormat == ZH_A_Format_M)
				&& (iOfficeType == ZH_BSC_M)) // 条件表达式的续行在第一个条件处对齐
				{
				TestSomething();
				}
				for (long_initialization_statement;
				long_condiction_statement;    // for循环语句续行在初始化条件语句处对齐
				long_update_statement)
				{
				TestSomething();
				}
				// 函数声明的续行在第一个参数处对齐
				BYTE ReportStatusZHeckPara(BYTE ucCallNo,
				                    BYTE ucStatusReportNo);
				// 赋值语句的续行应在赋值号处对齐
				fTotalTotle = fTotalTotle + faCustomerPurZHases[iID]
				+fSalesTax(faCustomerPurZHases[iID]);
											

2.4.2 【规则】函数声明时,类型与名称不允许分行书写。

正例:


				double  CalcArea(double dWidth, double dHeight);
											

反例:


				double
				CalcArea(double dWidth, double dHeight);
											

注 释

注释是软件可读性的具体体现。程序注释量一般占程序编码量的20%,软件工程要求不少于20%。程序注释不能用抽象的语言,类似于"处理"、"循环"这样的计算机抽象语言,要精确表达出程序的处理说明。避免每行程序都使用注释,可以在一段程序的前面加一段注释,具有明确的处理逻辑。

注释必不可少,但也不应过多,不要被动的为写注释而写注释

3.1 【规则】类、方法、属性的注释采用XML文档格式注释。

代码间多行注释为“/* … */”,单行注释采用“// …”。

正例:


				public class Test
				{
				    //数据成员    (单行注释)
				    private int m_iProperty;
				    /// <summary>
				    /// 示例属性
				    /// </summary>
				    public int Property
				    {
				    	get
				    	{
				    		return m_iProperty;
				    	}
				    	/* set(	多行注释)
				            {
				            m_iProperty = value;
				            } */
				    }
											

3.2 【规则】一般情况下,源代码有效注释量必须在20%以上。

说明:注释的原则是有助于对程序的阅读理解,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。有效的注释是指在代码的功能、意图层次上进行注释,提供有用、额外的信息。

3.3 【规则】注释使用中文。

说明:注释使用中文,主要给内部员工使用。

3.4 【规则】类、接口头部应进行XML注释。

说明:注释必须列出:内容摘要、版本号、作者、完成日期、修改信息等。

正例:


				/// <summary>
				///版权所有: 版权所有(C) 2013,华跃博弈
				///内容摘要: 本类的内容是…..
				///完成日期:2013年3月1日
				///版    本:V1.1
				///作    者:王五
				///
				///修改记录1:
				///修改日期:2013年9月10日
				///版 本 号:V1.2
				///修 改 人:王五
				///修改内容:对方法……进行修改,修正故障BUG……。
				///修改记录2:
				///修改日期:2013年3月20日
				///版 本 号:V1.3
				///修 改 人:王五
				///修改内容:对方法……进行进一步改进,修正故障……。
				/// <summary>
											

3.5 【规则】包含在{ }中代码块的结束处加注释。

针对(多分支、多重嵌套的条件语句或循环语句)。

说明:此时注释可以用英文,方便查找对应的语句。

正例:


				void Main()
				{
				if (…)
				{
				…
					while (…)
				{
				…
				}  /*end of while(…) */  	// 指明该条while语句结束
				…
				}  /*end ofif (…) */          // 指明是哪条语句结束
				}  /* end of void main()*/    	// 指明函数的结束
											

3.6 【规则】注释应与其描述的代码相近

对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。

说明:在使用缩写时或之前,应对缩写进行必要的说明。

正例:


				如下书写比较结构清晰
				/* 获得子系统索引 */
				iSubSysIndex = aData[iIndex].iSysIndex;
				/* 代码段1注释 */
				[ 代码段1 ]
				/* 代码段2注释 */
				[ 代码段2 ]
											

反例1:


				如下例子注释与描述的代码相隔太远。
				/* 获得子系统索引 */
				iSubSysIndex = aData[iIndex].iSysIndex;
											

反例2:


				如下例子注释不应放在所描述的代码下面。
				iSubSysIndex = aData[iIndex].iSysIndex;
				/* 获得子系统索引 */
											

反例3:


				如下例子,显得代码与注释过于紧凑。
				/* 代码段1注释 */
				[ 代码段1 ]
				/* 代码段2注释 */
				[ 代码段2 ]
											

3.7 【规则】注释与其上面的代码用空行隔开

说明:代码不要过于紧凑

反例:


				//注释
				程序代码 one //注释
				程序代码 two
				正例:
				//注释
				程序代码 one
				//注释
				程序代码 two
											

3.8 【规则】注释与所描述内容进行同样的缩排。

说明:可使程序排版整齐,并方便注释的阅读与理解。

正例:


				如下注释结构比较清晰
				int TestSomething(void)
				{
				/* 代码段1注释 */
				  [ 代码段1 ]
				    /* 代码段2注释 */
				  [ 代码段2 ]
				}
											

反例:


				        如下例子,排版不整齐,阅读不方便;
				        int TestSomething(void)
				        {
				/* 代码段1注释 */
				        [ 代码段1 ]
				/* 代码段2注释 */
				        [ 代码段2 ]
				        }
											

3.9 【规则】对分支语句(条件分支、循环语句等)必须编写注释。

说明:这些语句往往是程序实现某一特殊功能的关键,对于维护人员来说,良好的注释有助于更好的理解程序,有时甚至优于看设计文档。

〖建议3-1〗通过对函数或过程、变量、结构等正确的命名以及合理地组织代码结构,使代码成为自注释的。

说明:清晰准确的函数、变量命名,可增加代码的可读性,减少不必要的注释。

〖建议3-2〗尽量避免在注释中使用缩写

说明:注释使用缩写时,应对缩写进行必要的说明。

命名规则

好的命名规则能极大地增加可读性和可维护性。同时,对于一个有上百个人共同完成的大项目来说,统一命名约定也是一项必不可少的内容。本章对程序中的所有标识符(包括命名空间、变量名、常量名、控件名、参数名、属性名、方法名、类名、接口等)的命名做出约定。

4.1【规则】标识符要采用英文单词或其组合

说明:标识符应当直观且可以拼读,程序中的英文单词一般不要太复杂,用词应当准确。

4.2【规则】标识符

只能由26个英文字母,10个数字,及下划线的一个子集来组成,并严格禁止使用连续的下划线,下划线也不能出现在标识符头或结尾(预编译开关除外)

说明:这样做的目的是为了使程序易读。因为 variable_name 和 variable__name 很难区分,下划线符号‘_’若出现在标识符头或结尾,容易与不带下划线‘_’的标识符混淆。

4.3【规则】标识符的命名应当符合缩写拼音的原则。

说明:较短的单词可通过去掉“元音”形成缩写,较长的单词可取单词的头几个字母形成缩写,一些单词有大家公认的缩写,常用单词的缩写必须统一。

正例:

如下单词的缩写能够被大家认可:


				temp 可缩写为  tmp  ;
				flag 可缩写为  flg  ;
				statistic 可缩写为  stat ;
				increment 可缩写为  inc  ;
				message   可缩写为  msg  ;
											

规定的常用缩写如下:

常用词 缩写
Argument Arg
Buffer Buf
Clear Clr
Clock Clk
Compare Cmp
Configuration Cfg
Context Ctx
Delay Dly
Device Dev
Disable Dis
Display Disp
Enable En
Error Err
Function Fnct
Hexadecimal Hex
High Priority Task HPT
I/O System IOS
Initialize Init
Mailbox Mbox
Manager Mgr
Maximum Max
Message Msg
Minimum Min
Multiplex Mux
Operating System OS
Overflow Ovf
Parameter Param
Pointer Ptr
Previous Prev
Priority Prio
Read Rd
Ready Rdy
Register Reg
SZHedule SZHed
Semaphore Sem
Stack Stk
SynZHronize Sync
Timer Tmr
Trigger Trig
Write Wr

4.4【规则】程序中不要出现仅靠大小写区分的相似的标识符

4.5【规则】用反义词组命名具有互斥意义的变量或函数

说明:下面是一些在软件中常用的反义词组。


				add/remove; begin/end;create/destroy;insert/delete;
				first/last; get/release; increment/decrement; put/get;
				add/delete; lock/unlock; open/close;          min/max;
				old/new;start/stop;  next/previous;       source/target;
				show/hide;send/receive;source/destination;  cut/paste;
				up/down
											

4.6【规则】常量名都要使用大写字母, 用下划线 ‘_’ 分割单词。

正例:


				如 DISP_BUF_SIZE、MIN_VALUE、MAX_VALUE 等等。
											

4.7【规则】注意单个字符变量名

一般变量名不得取单个字符(如l等)作为变量名,变量名不要过长,局部循环变量除外。

说明:局部变量,如果用单个字符表示,很容易出错(如l写成1),编译时查不出的,则有可能增加排错时间。记得简化变量名称。

4.8【规则】使用一致的前缀来区分变量的作用域。

说明:变量活动范围前缀规范如下:


				m_  :  类的成员变量(属性所对应的变量)
				空  :  局部变量不加范围前缀
											

4.9【规则】使用一致的小写类型指示符作为前缀来区分变量的类型。

说明:常用变量类型前缀列表如下:


				i      	:int
				f      	:float
				d	:double
				dcm     : decimall
				ZH	:ZHar
				l       :long
				bt      :byte
				sbt     :sbyte
				b      	:bool
				sht     :short
				usht    :ushort
				ul	:ulong
				ar     	:array
				str    	:string
				st	:struct
											

以上前缀可以进一步组合,在进行组合时,数组类型的前缀指示符必须放在变量类型前缀的首位。

4.10【规则】参数名应由前缀+变量名主体组成

变量名的主体应当使用“名词”或者“形容词+名词”,且首字母必须大写。

说明:前缀为变量类型前缀。

4.11【规则】方法名

用大写字母开头的单词组合而成,应当使用“动词”或者“动词+名词”。

说明:方法名力求清晰、明了,通过方法名就能够判断方法的主要功能。方法名中不同意义字段之间不要用下划线连接,而要把每个字段的首字母大写以示区分。函数命名采用大小写字母结合的形式,但专有名词不受限制。

4.12【规则】遵循统一的规范来书写命名空间的声明

标识符用点号分隔开,且必须以HyBy开头。

说明:以HyBy开头,随后部分是系统、模块等。

4.13【规则】类名采用大小写结合的方法

构成类名的每个单词的首字母的首字母也必须大写。在构成类名的单词之间不用下划线。

说明:

1.名字应该能够标识事物的特性。

2. 名字尽量不使用缩写,除非它是众所周知的。

3.名字可以有两个或三个单词组成,但通常不应多于三个。

4.在名字中,所有单词第一个字母大写。

4.14【规则】接口命名在名字前加上“I”前缀,其它和类命名规范相同。

〖建议4-1〗尽量避免名字中出现数字编号,如Value1、Value2等,除非逻辑上的确需要编号。

声明

5.1【规则】一行只声明一个变量。

正例:


				intiLevel;
				intiSize;
											

反例:


				intiLevel,iSize;
											

5.2【规则】一个变量有且只表示一个功能

说明:同一变量取值不同时,其代表的意义也不同。

〖建议5-1〗变量声明应该只放在代码段的开始部分。最好不要到使用时才声明变量。对象类变量在函数体结束后,手工设置为null值,以利于资源的回收。

正例:


				void Method()
				{
				    int iTest = 0;//方法块的开始

				    //其它语句
				}
											

表达式与语句

表达式是语句的一部分,表达式和语句虽然看起来比较简单,但使用时不小心会造成重大错误,而且不易查觉。正确使用表达式和if、for、while、goto、switZH等基本语句。

6.1【规则】一条语句只完成一个功能。

说明:复杂的语句阅读起来,难于理解,并容易隐藏错误。变量定义时,一行只定义一个变量。

正例:


				int  iHelp;
				int  iBase;
				int  iResult;
				iHelp= iBase;
				iResult = iHelp + GetValue(iBase);
											

反例:


				int iBase, iResult;                 // 一行定义多个变量
				iResult = iBase + GetValue(iBase); // 一条语句实现多个功能,iBase有两种用途。
											

6.2【规则】在表达式中使用括号,使表达式的运算顺序更清晰。

说明:由于将运算符的优先级与结合律熟记是比较困难的,为了防止产生歧义并提高可读性,即使不加括号时运算顺序不会改变,也应当用括号确定表达式的操作顺序。

正例:


				if (((iYear % 4 == 0)&& (iYear % 100 != 0)) || (iYear % 400 == 0))
											

反例:


				if (iYear % 4 == 0 && iYear % 100 != 0 || iYear % 400 == 0)
											

6.3【规则】避免表达式中的附加功能,不要编写太复杂的复合表达式。

说明:带附加功能的表达式难于阅读和维护,它们常常导致错误。对于一个好的编译器,下面两种情况效果是一样的。

正例:


				ariVar[1] = ariVar[2] + ariVar[3];
				ariVar[4]++;
				iResult = ariVar[1] + ariVar[4];
				ariVar[3]++;
											

反例:


				iResult = (ariVar[1] = ariVar[2] + ariVar[3]++) + ++ariVar[4] ;
											

6.4【规则】不可将浮点变量用“==”或“!=”与任何数字比较。

说明:无论是float还是double类型的变量,都有精度限制。所以一定要避免将浮点变量用“==”或“!=”与数字比较,应该转化成“>=”或“<=”形式。

正例:


				if ((fResult >= -EPSINON) && (fResult <= EPSINON))
											

反例:


				if (fResult == 0.0) 	// 隐含错误的比较
				其中EPSINON是允许的误差(即精度)。
											

6.5【规则】switZH语句

每一个case分支必须使用break结尾,最后一个分支必须是default分支。

说明:避免漏掉break语句造成程序错误。同时保持程序简洁。对于多个分支相同处理的情况可以共用一个break,但是要用注释加以说明。

正例:


				switZH (iMessage)
				{
				    case SPAN_ON:
				    [处理语句]
				    break;
				    case SPAN_OFF:
				    [处理语句]
				    break;
				    default:
				    [处理语句]
				    break;
				}
											

6.6【规则】不可在for 循环体内修改循环变量,防止for 循环失去控制。

〖建议〗循环嵌套层数不大于3次。

〖建议〗do while语句和while语句仅使用一个条件。

说明:保持程序简洁。如果需要判断的条件较多,建议用临时布尔变量先计算是否满足条件。

正例:


				BOOLEAN bCondition;
				do
				{
				    ……..
				    bCondition = ((tAp[iPortNo].bStateAcpActivity != PASSIVE)
				    || (tAp[iPortNo].bStateLacpActivity != PASSIVE))
					&& (abLacpEnabled[iPortNo])
					&& (abPortEenabled[iPortNo])

				     }while (bCondition);
											

〖建议〗当switZH语句的分支比较多时,采用数据驱动方式。

说明:当switZH语句中case 语句比较多时,会降低程序的效率。

〖建议〗如果循环体内存在逻辑判断 并且循环次数很大,宜将逻辑判断移到循环体的外面。

说明:下面两个示例中,反例比正例多执行了NUM-1次逻辑判断。并且由于前者总要进行逻辑判断,使得编译器不能对循环进行优化处理,降低了效率。如果NUM非常大,最好采用正例的写法,可以提高效率。

const int NUM=1000;

正例:


				if (bCondition)
				{
				    for (i = 0; i < NUM; i++)
				    {
				    TestSomething();
				    }
				}
				else
				{
				    for (i = 0; i < NUM; i++)
				    {
					TestOtherthing();
				    }
				}
											

反例:


				for (i = 0; i < NUM; i++)
				{
				if (bCondition)
				    {
				    TestSomething();
				    }
				else
				    {
				     TestOtherthing();
				    }
				}
											

〖建议〗for语句的循环控制变量的取值采用“半开半闭区间”写法。

正例:


				int  aiScore[NUM];
				…
				for (i = 0; i < NUM; i++)
				{
				printf(“%d\n”,aiScore[i])
				}
											

反例:


				int  aiScore[NUM];
				…
				for (i = 0; i <= NUM-1;i++)
				{
				printf(“%d\n”,aiScore[i]);
				}
											

相比之下,正例的写法更加直观,尽管两者的功能是相同的。

类和接口

7.1【规则】类内部的代码布局顺序:数据成员、属性、构造函数、方法。

正例:


				public class Test
				{	

				private int m_iProperty;	//数据成员
					public int Property        //属性
					{
						get
						{
							return m_iProperty;
						}
						set
						{
							m_iProperty = value;
						}
					}
					public Test()         //构造函数
					{
					}
					public string Operation1(long lParam1, string strParam2)  //方法
					{
						return null;
					}
				}
											

〖建议7-1〗功能相关的方法放在一起。

说明:如接口中关系较紧密的的几个方法,类属性的get和set 方法,有调用关系的方法,重载的方法等有相近或相关的方法尽可能放在一起,方便阅读。

7.2〖建议7-2〗方法的参数个数不宜超过8个。

说明:过多的函数参数会导致性能降低。

7.3〖建议7-3〗使程序结构体现程序的目的。

正例:


				return booleanExp;
											

反例:


				if (booleanExp)
				{
				return true;
				}
				else
				{
				return false;
				}
											

7.4〖建议7-4〗保证内部类定义成private,提高类的封装性。

7.5〖建议7-5〗嵌套内部类不能超过两层。

7.6〖建议7-6〗一个接口可以有多个实现类,实现类共同的变量在接口里声明。

说明:

格式化包含单个public类的C#源文件。接口格式化与之类似,


				using System;
				namespaceHyBy.xxx
				{
				/// <summary>
				///版权所有(C)2013,华跃博弈
				///内容摘要: 本文件的内容是…..,包括主要……模块、……函数及功能是…….
				/// 完成日期:2013年3月1日
				///版    本:V1.0
				///作    者:王五
				///
				///修改记录1:
				///修改日期:2013年3月10日
				///版 本 号:V1.3
				///修 改 人:王五
				///修改内容:对方法……进行修改,修正故障BUG。
				///修改记录2:
				///修改日期:2013年3月20日
				///版 本 号:V1.3
				///修 改 人:王五
				///修改内容:对方法……进行进一步改进,修正故障……。
				    /// <summary>
				    publicclass Test
				    {
				       //数据成员
				       privateint m_iProperty;
				       /// <summary>
				      ///示例属性
				      /// <summary>
				      publicint Property
				       {
				            get
				            {
				                return m_iProperty;
				            }
				            set
				            {
				                m_iProperty = value;
				            }
				        }
				        /// <summary>
				        ///示例方法
				        /// <summary>
				        ///参数1
				        ///参数2
				        ///返回值
				        publicstring Operation1(long Param1, string Param2)
				        {
				            returnnull;
				        }
				    }
				}
											

throw语句抛出的异常

说明:必须在方法的注释中标明,对于所调用的其他方法所抛出的异常,选择主要的在注释中说明。对于非RuntimeException ,即throws子句声明

会抛出的异常,必须在方法的注释中标明。说明:异常注释用@exception或@throws表示,但推荐用@exception标注Runtime 异常,@throws标注非Runtime 异常。异常的注释必须说明该异常的含义及什么条件下抛出该异常。

JAVASCRIPT规范

JavaScript 程序应该尽量放在 .js 的文件中,需要调用的时候在 页面文件 中以 <script src="jstest.js"> 的形式包含进来。

JavaScript 代码如果不是该页面文件专用,则应尽量避免在页面文件中直接编写 JavaScript 代码。这样会增加 页面 文件的容量,影响代码的压缩和缓存的使用及加载速度。

8.1行规则长度

说明:每行代码应小于 80 个字符。如果代码较长,应尽量选择换行,下一行代码应缩进 4个空格(此处跟C#规范相同不能用Tab键 一个Tab用4个空格代替)。

8.2行规则结束

说明:换行应选择在操作符和标点符号之后,最好是在逗号‘,‘之后,而不要在变量名、字符串、数字、或‘)‘ ‘]‘ ‘++‘ ‘--‘等符号之后换行


				<script language="javascript">
				 var valueA = 1; 

				反例
				 var valueB = valueA
				       +1; 

				正例
				 var valueC = valueB +
				       valueA;
				 alert(valueB);
				 alert(valueC);
				</script>
											

8.3变量命名

说明:JavaScript 中的标识符的命名规则:

•以字母、下划线‘_‘或美元符号‘$‘开头

•允许名称中包含字母,数字,下划线‘_‘和美元符号‘$‘

•区分大小写

变量、参数、成员变量、函数等名称均以小写字母开头,构造器的名称以大写字母开头。下划线‘_‘开头的变量一般习惯于标识私有 / 局部成员。而美元符号‘$‘开头的变量习惯于标识系统相关,比如系统进程等。应避免用下划线‘_‘或美元符号‘$‘来命名标识符。尽可能地降低代码的阅读难度。

命名的规范化,有助于编程模式的规范化。

8.3.1变量的声明

以功能动词的英文命名函数,以其名词命名变量

8.3.1.1在函数的开始应先用 var 关键字声明函数中要使用的局部变量

说明:防止变量复制时出现错误,这是因为 JavaScript 中只有函数的 {} 表明作用域,用 var 关键字声明的局部变量只在函数内有效,而未经 var 声明的变量则被视为全局变量。

8.3.1.2每个变量单独占一行

正例:


				Var iHelp;
				Var iLose;
											

反例:


				Var iHelp,iLose
											

8.3.2函数的声明

8.3.2.1注意空格

函数名紧接左括号‘(‘之间,而右括号‘)‘和后面的‘{‘之间要有个空格

若函数为匿名 / 无名函数,则 function 关键字和左括号‘(‘之间要留空格,否则可能误认为该函数的函数名为 function

8.4注释

8.4.1脚本头文档注释

				/*------------------------------------------------------------------
				*
				*      编写日期:
				*      功能 模块 用途
				*      作者:
				*      脚本名称:
				*
				---------------------------------------------------------------------*/
											
8.4.2脚本内部注释

说明:


				<script language="javascript">
				 //定义全局变量正例
				var valueA = 0;     // valueA赋值0反例
				var valueB = 1;
				 //执行完f1方法 等待50秒正例
				setTimeout(f1,50000);
				</script>
											
8.4.3HTML文档脚本注释:

说明:



				<script type="text/javascript" src="js/login-min.js"></script>

				<script type="text/javascript" src="js/login-min.js"></script>
											

8.4.4语句

8.4.4.1分号必要性

说明:一行结束必须加上分号

8.4.4.2一行最多有一个语句

说明:表达式和 return 放在同一行,return 关键字后若没有返回表达式,则返回 undefined

正例:


				Function funCel()
				{
				Return  a+b;
				}
				正例:
				Function funCel()
				{
				Return
				a+b;
				}
											

8.4.5<!DOCTYPE> 声明

说明:HTML 4.01 中的 doctype 需要对 DTD 进行引用,因为 HTML 4.01 基于 SGML。而 HTML 5 不基于 SGML,因此不需要对 DTD 进行引用,但是需要 doctype 来规范浏览器的行为(让浏览器按照它们应该的方式来运行。)。

正例:


				<!DOCTYPE HTML>
											

原文地址:https://www.cnblogs.com/zhanfuzhi/p/zhan1.html

时间: 2024-10-11 10:33:20

C# 开发代码标准的相关文章

Android开发代码规范(转)

Android开发代码规范 1.命名基本原则    在面向对象编程中,对于类,对象,方法,变量等方面的命名是非常有技巧的.比如,大小写的区分,使用不同字母开头等等.但究其本,追其源,在为一个资源其名称的时候,应该本着描述性以及唯一性这两大特征来命名,才能保证资源之间不冲突,并且每一个都便于记忆. 对于理解应用程序的逻辑流,命名方案是最有影响力的一种帮助.名称应该说明“什么”而不是“如何”.命名原则是:使名称足够长以便有一定的意义,并且足够短以避免冗长.唯一名称在编程上仅用于将各项区分开.以下几点

iOS 开发代码规范有哪些

对于刚刚入门ios的同学来说,iOS 开发代码规范是很重要的知识的,这里就给大家简单总结了一下. 一.工程规范 1.功能分类 根据所做功能的不同,分为不同的功能模块,比如登录模块,首页模块,个人模块等,根据不同的功能,代码必须要放在不同功能的文件夹下. 2.代码文件分类 不管是MVC模式,MVVM模式,或是其他设计模式,在不同的功能模块下,视图控制器(Controllers),视图(Views),模型类(Models),也必须要分别存放. 3.第三方库分类 工程中会经常使用第三方库,在引入第三方

jQuery代码开发技巧收集,jquery常用的开发代码

jQuery代码开发技巧收集,jquery常用的开发代码 今天分享一个jquery常用的开发代码,大部分是网友总结的,总共60条.后期我也会陆续完善! 把我在开发中常用的写在这里,希望持续关注~~ 1. 使用siblings()来处理同类元素 // Rather than doing this $('#nav li').click(function(){ $('#nav li').removeClass('active'); $(this).addClass('active'); }); //

Android开发代码的效率问题

实际上,不仅仅是android手机开发,所有的软件开发都要注意代码效率的问题!一般来说,实现相同的功能尽量较少地使用内存,最少的指令是一个优秀开发者需要时刻注意的!这里从两点来讨论这个问题: (一)数据类型选择 首先来讨论基本数据类型的选择.对于一个32位的ARM,我们来看看两个16位的数相加的汇编代码: 000016d0 <add_16_16> 16d0: e0810000      add  r0, r1, r0 16d4: e6bf0070        sxth r0,r0 16d8:

iOS团队开发代码规范

iOS 开发代码规范 1.命名 https://github.com/Chinamobo/iOS-Team-Norms/blob/master/CodeStyle.md#naming-basic-principle https://github.com/foxsofter/ios-code-style https://github.com/andy0323/iOS-Code-Specification 新建.h,.m文件时,文件名称应与

好的前端代码标准

开始学前端的时候,遇到什么问题,从网上查资料,解决了就pass,不过心里心里还是比较没谱的,因为不符合学院派的作风.起码也得知道前端的原则是什么,好的前端代码的标准是什么,才能评价自己的代码. 最近终于抽空看了看有关JS的书,总算心里有了点底. 一.层次分离 把前端分为三层:结构层.表示层.行为层,这三样分别对应者HTML.CSS.JS.基本的现状是: 1. HTML里能嵌入CSS和JS 2. CSS和JS功能上有重叠的地方 所谓层次分离就是不混淆各自的主要功能,狭义上说就是HTML定义结构,C

记录开发代码量的小程序

这段时间在开发网站,想要去记录自己的开发代码量,所以写了一个小脚本,用来记录,代码如下: #-*- coding: UTF-8 -*- #用来检测当前的代码量 import sys,os count = 0 def readfile(file): global count f = open(file,'r') read = f.readlines() for i in read: count+=1 f.close() def check(currentpath): s = os.listdir(

御安全浅析安卓开发代码混淆技术

御安全浅析安卓开发代码混淆技术[关键词:代码混淆,Android应用加固,移动应用保护,APP保护,御安全] 提高native代码的安全性有什么好办法吗?答案是肯定的,今天我们就来介绍一种有效对抗native层代码分析的方法--代码混淆技术.随着移动互联网的快速发展,应用的安全问题不断涌现出来,于是越来越多的应用开发者将核心代码由java层转到native层,以对抗成熟的java逆向分析工具,然而如果native层的代码如果没有进行任何保护,还是比较容易被逆向分析工作者获取其运行逻辑,进而完成应

十大开发代码原则

本原则是本人结合项目的实施开发编写代码情况,对多年以来带领项目实施奋战在开发一线经验的提炼与概括.这十条开发指导原则,最基本的思想是"高效,高质量的写出满足业务功能目标的代码."每人可以结合当前项目的实际情况应用,可以补充,修订删改进一步总结提炼.1.先开发简单明确的功能模块,后开发复杂的功能模块.2.先做简单的子功能,再做稍微复杂的子功能,后开发有难度逻辑复杂的子功能.3.以满足业务功能要求为主要目标,不保留无用的垃圾代码.写出高质量满足功能要求的代码,是建立在对业务需求理解,明确业