代码编写规范

简介: 代码编写规范

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

注释规范

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。


相关文章
|
7月前
|
前端开发 JavaScript
工作中代码书写规范
前端代码规范增进代码整洁与团队协作,降低维护成本。包括代码规范、风格和注释建议:选择编程语言对应的编码规范,统一命名、缩进和换行规则;注重代码风格的一致性、简洁性和可配置性;注释要简洁明了,位于关键位置。通过制定规范文档、使用代码检查工具、定期代码审查和鼓励改进来执行规范,提升团队效率和代码质量。
75 0
|
安全 程序员 C++
代码规范:函数设计
除非告诉人们“危险”是什么,否则这个警告牌难以起到积极有效的作用。难以理解的断言常常被程序员忽略,甚至被删除。 ↩︎
97 0
|
存储 设计模式 人工智能
规范:前端代码开发规范
规范:前端代码开发规范
1611 0
|
7月前
|
Java
Java开发规范(简洁明了)
Java开发规范(简洁明了)
|
7月前
|
前端开发 JavaScript 持续交付
前端代码审查规范
前端代码审查规范
166 0
|
前端开发 JavaScript
|
数据采集 算法 Shell
【C#编程最佳实践 七】代码书写规范实践
【C#编程最佳实践 七】代码书写规范实践
137 0
【C#编程最佳实践 七】代码书写规范实践
|
程序员
代码的规范
代码的规范
166 0
|
开发工具 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插件
158 0
|
前端开发 JavaScript
前端代码如何规范编写?
前端代码如何规范编写?
120 0
下一篇
DataWorks