代码编写规范

在这里插入图片描述

规范编写代码可以体现程序员的专业度,同时方便交流和维护。

注释规范

1. 自建代码文件注释
对于自己创建的代码文件(如函数、脚本),在文件开头,一般编写如下注释:
/*************************************************
作者:
小组:
说明:
创建日期:
版本号:
**********************************************/
2. 标准注释
在模块、类、属性、方法前一行添加注释,以便调用的时候提示用户
下以方法声明做例子:

        /// <summary>
        /// depiction:<对该方法的说明>
        /// </summary>
        /// <param name="<参数名称>"><参数说明></param>
        /// <returns>
        ///<对方法返回值的说明,该说明必须明确说明返回的值代表什么含义>
      	/// </returns>

如果模块只进行部分少量代码的修改时,则每次修改须添加以下注释:

///修改人:
///修改日期:< YYYY-MM-DD >
 ///备份: 
/* 原代码内容*/ 
将原代码内容注释掉,然后添加新代码使用以下注释:
///添加人: 
///添加日期: <YYYY-MM-DD> 
代码内容
///结束:                      

对于重构的类文件,需要对原来的类文件做备份,然后放在同级目录下,在原有文件名后面添加后缀"_BAK",以便日后版本升级时整理源码。
3. 代码间注释
代码间注释分为单行注释和多行注释:
单行注释:
//<单行注释>
多行注释:
/多行注释1
多行注释2
多行注释3
/
代码中遇到语句块时必须添加注释(if,for,foreach,……),添加的注释必须能够说明此语句块的作用和实现手段(所用算法、循环条件、不同分支的意义等等)。

命名总体规则

 名字应该能够标识事物的特性,并且与业务挂钩。
 名字一律使用英文单词,而不能为拼音。
 名字可以有两个或三个单词组成,但不应多于4个,控制在3至30个字母以内。
 在名字中,多个单词用大写第一个字母(其它字母小写)来分隔。例如:IsSuperUser。

1. 参数
 参数名称使用Camel大小写
 参数名称可缩写
2. 方法
 以动词开头。
 使用 Pascal 大小写。
 禁止缩写,除非名词本身含有缩写。如:AddStudentMgr ()
3. 属性 (property)
 以名词或形容词命名。
 使用 Pascal 大小写。
 禁止缩写。
4. 事件
 使用 Pascal 大小写。
 禁止缩写。
 名称命名使用 Event后缀。
 用动词或名词命名,带有时间意义,如:MouseMove事件、Closing 事件、Closed 事件。
 指定两个名为 sender 和 e 的参数。sender 参数表示引发事件的对象。e为事件类的实例。e参数类型使用适当而特定的事件类。
 用 EventArgs 后缀命名事件参数类。
5. 常量 (const)
 全部大写,单词间以“_”分隔。
 禁止缩写。
6. 字段
 private、protected 使用 Camel 大小写。
 禁止使用public。
7. 静态字段
 使用名词、名词短语或者名词的缩写命名静态字段。
 使用 Pascal 大小写。
8. 集合
 命名使用复数。
9. 范型
 以一个大写字母(建议优先使用T)表示类的类型,以一个小写字母(如:t)表示类名。
10. 缩进规则
使用一个“Tab”为每层次缩进(默认4个空格,有的规范也要求2个空格,依要求而定,所有IDE都可以设置)。
11. 小括号规则
 不要把小括号和关键词(if 、while等)紧贴在一起,要用空格隔开它们。如:
if (true)
{

        }

 不要把小括号和函数名紧贴在一起。
 除非必要,不要在Return返回语句中使用小括号。因为关键字不是函数,如果小括号紧贴着函数名和关键字,二者很容易被看成是一体的。
12. 单语句规则
除非这些语句有很密切的联系,否则每行只写一个语句。
13. 模块化规则
某一功能,如果重复实现一遍以上,即应考虑模块化,将它写成通用函数。并向小组成员发布。同时要尽可能利用其它人的现成模块。

14. 函数复杂度规则
单个函数的功能不能过于复杂,不能超过以下限定:
 单一功能子函数代码不得超过50行、形参个数不得超过7个、程序嵌套深度不得超过7层。
 圈复杂度必须在15以内,对程序的修改或扩展不得增加其原有圈复杂度。

编码风格规则

编码过程中需遵循以下风格习惯:
 代码未写,文档先行,注释必须按照固定统一范式撰写。
 关系运算必须常量在左、变量在右。
 不许使用复杂的运算表达式,必要时添加括号而不依赖于优先级。
 魔鬼数字需用宏定义替代。
 局部变量必须初定义、避免不必要的内存操作、内存操作必须考虑异常处理。

1. 版本管理规则
本项目中,每个任务在完成一个稳定的版本后,都应打包并且归档。源码包的版本号由圆点隔开的两个数字组成,第一个数字表示发行号,第二个数字表示该版的修改号。具体用法如下:
 当源码包初版时,版本号为 V1.00;
 当源码包被局部修改或bug修正时,发行号不变,修改号第二个数字增1。例如,对初版源码包作了第一次修订,则版本号为 V1.01;
 当源码包在原有的基础上增加部分功能,发行号不变,修改号第一个数字增1,例如,对V1.12版的基础上增加部分功能,则新版本号为 V1.20;
 当源码包有重要修改或局部修订累积较多导致源码包发生全局变化时,发行号增1。例如,在 V1.15 版的基础上作了一次全面修改,则新版本号为 V2.00。

评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

倔强的腿毛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值