代码编写规范

简介: 代码编写规范

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

注释规范

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。


相关文章
|
2月前
|
消息中间件 运维 测试技术
究竟什么样的开发流程是规范的?
究竟什么样的开发流程是规范的?
92 0
|
9月前
|
存储 设计模式 人工智能
规范:前端代码开发规范
规范:前端代码开发规范
1062 0
|
9月前
|
程序员
代码的规范
代码的规范
113 0
|
9月前
|
开发工具 git
代码统一风格、代码规范和提交规范
1、安装模块 全局安装 eslint、commitlint 、 check-prettier npm install eslint commitlint check-prettier -g 本地安装 npm install eslint-config-prettier  stylelint  stylelint-config-prettier stylelint-config-standard husky  @commitlint/config-conventional -D VSCode 安装 Eslint和Prettier插件
117 0
|
10月前
|
前端开发 JavaScript
前端代码如何规范编写?
前端代码如何规范编写?
92 0
|
10月前
|
数据采集 算法 Shell
【C#编程最佳实践 七】代码书写规范实践
【C#编程最佳实践 七】代码书写规范实践
88 0
【C#编程最佳实践 七】代码书写规范实践
|
前端开发 JavaScript
|
JSON 前端开发 JavaScript
规范(一):代码规范
规范(一):代码规范
规范(一):代码规范
|
程序员 Go 开发者
规范的代码风格要求 | 学习笔记
简介:快速学习规范的代码风格要求
110 0
规范的代码风格要求 | 学习笔记
|
缓存 监控 架构师
开发流程规范
这是近期在公司做的一次分享,这几年的互联网开发,算比较幸运,团队一直践行完善这套规范,没有太多的阻碍,得益于公司整体氛围,以及团队对规范和写文档的不排斥,形成了良好的开发习惯 在这次分享后,发现好些大V也在谈规范,写文档,估计是前段时间阿里又发布了开发手册(华山版),借鉴于一下,对一些细节做些补充,整理出来
2031 0
开发流程规范