代码审查规范

代码审查规范

The Standardization Office was revised on the afternoon of December 13, 2020

代码审查规范

目录

引言............................................................ 错误!未定义书签。

目的.......................................................... 错误!未定义书签。说明.......................................................... 错误!未定义书签。

代码审查........................................................ 错误!未定义书签。

检查点........................................................ 错误!未定义书签。审查流程图.................................................... 错误!未定义书签。流程概述...................................................... 错误!未定义书签。具体流程...................................................... 错误!未定义书签。

建立任务................................................ 错误!未定义书签。

桌面检查................................................ 错误!未定义书签。

团体评审................................................ 错误!未定义书签。

Bug修复................................................ 错误!未定义书签。

Bug复检................................................ 错误!未定义书签。

引言

目的

检查开发/前端人员是否遵守开发规范中的规定

检查开发/前端人员是否代码审定表中的错误

检查代码是否存在逻辑错误或安全问题

说明

代码检查每月进行一次，根据《代码审查表》的内容进行检查，结果计入绩效考核-开发质量项。

代码审查

检查点

参见《代码审查表》。

审查流程图

类型

流程概述

1.建立任务：建立代码检查任务，指定需评审的项目或代码文件范围、参与评审的人员、定义问题类型

及严重级别等。

2.桌面检查阶段：开始各审查人独自评审，将可能出现的问题加入代码管理的Bug列表。

3.团队评审阶段：合并上步审查结果，统一讨论桌面检查阶段的问题，实施交叉检定，确定是否Bug，需

要修复的分配解决人员。

4.问题修复阶段：修改人修复分配给自己的问题，修复后修改Bug状态，审查人复查无误后，关闭Bug。具体流程

建立任务

1.选择一个要检查的项目。

2.确定此次检查的重点内容和主要关注的Bug类型。

3.新建OA流程发起新的检查任务，告知相关人员。

4.定义错误严重级别，划分各审查人检查范围，指定Bug文档位置。

桌面检查

1.获取要检查的源代码更新，使用分析工具寻找Bug。

2.简单的风格类Bug如缩进、换行格式等，可直接修改后等待发布。

3.人工检查代码，查找使用工具无法找到的错误。

4.使用文档记录Bug。标记问题类型及严重性，出现位置和操作场景。

5.桌面检查完毕后，所有审查人将Bug文档合并至到源码管理工具。

团体评审

1.审查成员在一起，从源码管理工具获取更新的Bug文档。

2.按照文档交叉检定其他人提交的Bug是否存在，Bug描述是否完整。

3.Bug文档在集体确认后，一起讨论代码中的Bug存在问题及处理优先级。

4.对高优先级的Bug优先分配人手，并制定解决方案。

5.团队评审完毕后，更新Bug文档，并将确定需要处理的Bug分发给指定修改人。

Bug修复

1.个人回到自己的工位，更新最新的Bug文档，并获取指定给自己的Bug。

2.将分配给自己的问题，按解决方案的指定逐一修复，并进行测试。

3.将修改后的源代码提交至管理工具，修改指定给自己的Bug状态，修改Bug文档说明。

Bug复检

1.审查人更新最新的Bug文档，依据文档逐一检查Bug修改。

2.如有功能变动或逻辑变化，需要加入测试人员的黑盒测试，进行二次确认。

3.Bug修改未完成的，退回到Bug修复。

4.已修复的Bug，将复检结果更新至Bug文档。

5.所有Bug修复、复检完成后，联同风格类Bug合并进行发布部署。

C语言注释规范

C语言注释规范 1.注释原则 同一软件项目开发中，尽量保持代码注释规范和统一。 注释方便了代码的阅读和维护。 边写代码边注释，修改代码时要相应修改注释，保证注释和代码的一致性。 注释要简洁明确，不要出现形容词。 对于写的好的注释，我们将是第一个受益者。 大型软件开发中，通过别人的注释可以快速知道他人所写函数的功能，返回值，参数的使用。 2.文件头部的注释 示例： / * Program Assignment : 该文件的作用 * Author: 作者 * Date: 2013/8/6 14:34 * Description: 该文件的描述 *****/ /* * Source code in : 源代码的路径 * Function List: * initLinear 初始化线性表 * destoryLinear 释放线性表申请的空间 * isLinearEmpty 判断线性表是否为空 * isLinearFull 判断线性表是否为满 * getLinearElementValue 取得下标为index的元素的值 */ 注意：这个函数列表可以快速查询到我们想要了解的函数。 3.结构体，全局变量等的注释 示例： typedef POLYNOMIAL USER_TYPE; /* 新的数据类型的描述*/ int a; /* 全局变量的作用*/ /* 说明结构体的功能*/ typedef struct LINEAR { USER_TYPE *data; /* 每个成员的意义(作用) */ int maxRoom; /* 每个成员的意义(作用) */

int elementCount; /* 每个成员的意义(作用) */ }LINEAR; 4.函数的注释 在逻辑性较强的的地方加入注释，以便其他人的理解，在一定的程度上排除bug。 示例： /* * Function Name: getLinearElementIndex * Purpose: 取得元素的index值 * Params : * @LINEAR linear 线性表实例 * @USER_TYPE var 类型为USER_TYPE的实例 * @int (*)() cmp 提供接口，让用户定义具体比较函数 * Return: int 返回元素的index值 * Limitation: 如果返回-1，则代表不存在var的元素 */ int getLinearElementIndex(LINEAR linear, USER_TYPE var, int (*cmp)()) { /* * 如果逻辑太过复杂，这里写明该算法的过程和思路。 */ boolean found = FALSE; int i; for(i = 0; i < && !found; i++) if(cmp[i], var) == 0) found = TRUE; if(i >= i = NOT_FOUND; return i; }

代码走查

代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法, 代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。 最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题： 1. Comment 注释没写，或者格式不对，或者毫无意义 2. Coding Standard 没遵守代码规范 3. Existing Wheel 重复现成的代码，或者是开源项目，或者公司已有代码 4. Better practice Java或者开源项目，有更好的写法 5. Performance bottle and Improvement 性能瓶颈和提高 6. Code Logic Error 代码逻辑错误 7. Business Logic Error 业务逻辑错误 代码审查列出问题的类型，并有解决情况报告 11月23日 代码走查——项目走向成功的锦囊之一 说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。 一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。 这种做法在很多做软件开发组织中经常采用。但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。 随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。而是在设计、代码的品质上也有了更多的要求。有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。

代码编写规范

知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。

二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。

产品使用说明书编写模板

使用说明书模板 根据所需改写即可 远程抄表能源管理系统 使用说明书 XXXXXXXX XXXX 年XX 月 文档控制 修改记录 * 修改类型分为A一Added M—Mod辻ied D—Deleted 审阅人 存档 目录 1醞

1.1背景 1.2应用领域与使用对象 1.4参考资料 1.5术语与缩耳解释 2系统综述 2.1系统结构 2.2系统功能简介 2.3性能 2.4版权声明 3运行环境 3.1硕件设备要求 3.2支持软件 3.3数据结构 4系统操作说明 4.1安装与初始化 4.2子模块名称1 4.2. 1业务需求描述 4. 2. 2界面截屏以及界面字段解释 4. 2. 3操作说明 4. 3子模块名称2 4. 3. 1业务需求描述 4. 3. 2界面截屏以及界面字段解释 4.4出错处理和恢复 4. 3. 3操作说明

1概述

1?1背景 系统的开发背景和编写这个手册的U的。 1.2应用领域与使用对象 描述软件所能使用的领域以及使用对象等。 1.4参考资料 列出有关资料的作者、标题、编号、发表日期、岀版单位或资料来源，可包括 与该产品有关的已发表的资料 文档中所引用的资料，所采用的软件标准或规范或业务规则 列岀编写本说明书时查阅的Internet上杂志、专业著作、技术标准以及他们的网址 1?3术语与缩写解释 2系统综述 4.4出错处理和恢复

2.1系统结构 结合系统所具有的功能包括输入、处理和输出提供该软件的总体结构图表。 2.2系统功能简介 结合本软件的开发实际逐项地说明本软件所有具有各项功能。 2.3性能 给出一般情况下的运行性能指数等。 2.4版权声明 声明版权所有者以及盗版应承当的法律责任。 3运行环境 3.1硬件设备要求 列出本软件所要求的硬设备的最小配置，如： 1、处理器的型号、内存、硬盘容量； 2、所要求的外存储器、媒体、记录格式、设备的型号和台数、联机/脱机; 3、I/O设备（联机/脱机）； 4、数据传输设备和转换设备的型号、台数。 3. 2支持软件

程序代码注释编写规范

程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ COPYRIGHT (C), MicTiVo International. Co., Ltd. FileName: Author:

系统开发代码规范

系统开发代码规范北京慧点科技开发有限公司 2005年9月

目录 一、Domino网络域及组织的命名................................................................ 错误！未定义书签。 二、Domino服务器的命名............................................................................ 错误！未定义书签。 三、系统验证字的命名................................................................................. 错误！未定义书签。 四、用户和群组的命名................................................................................. 错误！未定义书签。 五、模块数据库的命名................................................................................. 错误！未定义书签。 六、数据库各设计元素的命名..................................................................... 错误！未定义书签。 七、编码规范................................................................................................. 错误！未定义书签。 八、产品开发规范......................................................................................... 错误！未定义书签。 九、提交数据库备份命名规范..................................................................... 错误！未定义书签。

产品使用说明书编写规定

产品使用说明书编写规定 1 本标准规定了产品使用说明书的基本要求和编写方法。 本标准适应于湖北京山轻工机械股份有限公司产品使用说明书的编写。 2 引用标准 下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版 时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列 标准最新版本的可能性。 工业产品使用说明书总则 JB/T5995 工业产品使用说明书机电产品使用说明书编写规定 3 基本要求 号或不同的字体表示， 或用特殊符号或颜色来强调。 使用说明书必须按下列等级和 告用 语提醒用户： —“危险”表示对高度危险要警惕； 表示对中度危险要警惕； 注意”表示对轻度危险要关注； 使用说明书应明确给出产品用途和适应范围， 并根据产品的特点和需要给出主要结 构、性 能、型式、规格和正确吊运、安装、使用、操作、维修、保养等的方法，以 及保护操作者 和产品的安全措施。 使用说明书内容的表述要科学、合理、符合操作程序，易于用户快速理解掌握。 对于复杂的操作程序，应多采用图示、图表、和操作程序图进行说明。 使用说明书中的图、表应和正文印在一起，图、表应按顺序编写序 3.8 具有几种不同和独 立功能的产品的使用说明书， 应先介绍产品的基本的和通常的功 能，然后再介绍其他方面的功能。 3.9 使用说明书应尽可能设想用户可能遇到的问题，并提供预防和解决的办法。 3.10应使用简明的标题和标注，以帮助用户快速找到所需内容。 3.11使用说明书应将机、电、气、液等融合一起编制，不能各行其是。 3.12外购件的使用说明书应附在相应的产品使用说明书上。编制产品使用说明书时， 除在产品使用说明书中简述其使用、 操作方法外， 还应注明详见某 某使用说 明书。 3.13使用说明书中的符号、代号、术语、计量单位应符合最新发布的国家法令、法规和 有关标 准的规定，并保持前后一致。 3.1 3.2 3.3 3.4 当需要时必须编制产品使用说明书，使用说明书是交付产品的组成部分。 使用说明书的开本幅面采用 16开，大于 16开的幅面应折页成 16 开。多页应装订 成册。 使用说明书可按产品型号编制， 也可按产品系列编制。 复杂产品和成套设备可按功 能单元、整机分别编制使用说明书， 再按产品型号、 用途组合成系统的使用说明书。 使用说明 书应对涉及安全方面的内容给出安全警告。 安全警告的内容应用较大的字 “做小” 3.5 3.6 3.7

程序代码注释编写规范

百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}

java代码走查计划书

WATER Corporation 代码走查计划书Version 2.0 XXX 2012/3/20

文档修改记录

目录 1.进度计划 (4) 2.待评审物 (4) 3.成员角色 (5) 4.基本原则 (5) 4.1代码评审原则 (5) 4.2评审指导文档 (6) 5.走查过程定义 (6) 5.1代码走查计划准备阶段 (6) 5.2个人代码走查阶段 (6) 5.3代码走查会议阶段 (7) 5.4缺陷修改与关闭 (7)

1.进度计划 小组代码走查活动时间进度安排如下所示： 2.待评审物 待评审物名称：银行系统取款模块源代码V1.0 （SC-Banking-Withdraw- V1.0） Figure 1 UML Model for Banking-Withdraw

3.成员角色 组长：制定代码走查的计划、安排代码走查活动职责分工、组织代码走查，确保代码走查的过程规范执行； 质量保证人员：制定CheckList，记录代码走查会议以及完成问题记录报告； 开发人员：完成代码，在代码走查中引领走查人员读代码，走查结束后并根据走查的问题记录报告完成代码修改； 评审人员：依据编程规范和CheckList执行代码走查，使用Jupiter工具记录发现的问题。 4.基本原则 4.1 代码评审原则 1.一次检查少于200～400行代码 2.努力达到一个合适的检查速度：每小时少于300～500行代码 3.有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟 4.在复审前，代码作者应该对代码进行注释 5.建立量化的目标并获得相关的指标数据，从而不断改进流程 6.使用检查表（checklist）肯定能改进双方（作者和复审者）的结果 7.验证缺陷是否真正被修复

产品说明注意事项

工业产品使用说明书的编写方法 一、编写工业产品使用说明书的基本要求 编写工业产品使用说明书应符合下列四个方面基本要求： 1．应明确具体规定产品的用途和使用方法 要根据产品的使用功能和特点，具体而明确地写明产品的用途和适用范围，同时写明主要结构、性能参数、型式和规格以及正确贮运、安装、使用（操作）、维修、保护等方法。 产品使用说明书可按产品型号编写，也可按产品系列编写。 2．涉及到安全、卫生和环境保护等方面要求必须写明 当产品具有危险和有害因素时，必须在产品使用说明书中写明保护产品和操作者的安全卫生措施，对易燃、易爆、有毒、有腐蚀性和有放射性的危险产品，更应在使用说明书上规定防范措施、注意事项以及发生意外时的紧急处理办法等内容。 对影响环境的产品，使用说明书上还应规定必要的保护环境方面的内容。此外，对一些耗能较大产品应说明节能措施。 3．复杂产品和成套设备应编写系统的使用说明书

对一些复杂产品和成套设备，可按其功能单元、整机分别编写使用说明书，再组合成一套系统的使用说明书。 4．简单产品可不写使用说明书 对一些冶金、矿产、建材等原材料类产品以及用于组装配套的一些元器件、零部件等简单产品，如其产品标准、产品手册、质量证明书等有关技术文件能满足用户需要时，可由这些技术文件代管产品使用说明书，不必另行编写产品使用说明书。 二、产品使用说明书的内容构成 一般工业产品使用说明书应包括下列内容： 1．产品概述 产品概述部分主要写明产品的用途，适用范围（必要时还应写明不适用范围），产品规格型号的含义，使用环境条件或工作条件等方面内容。 2．结构特征与工作原理 该部分叙述产品结构特点及其工作原理，包括主要部件或功能单元的结构，作用及其工作原理，辅助装置的功能结构及工作原理和各单元之间的机电联系，故障告警系统等。

程序代码注释编写规范

程序代码注释编写规范 XXX份公司

为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************

代码开发规范

代码开发规范 1 前言 1.1 为什么需要开发规范 编码规范对于程序员而言尤为重要，有以下几个原因： * 一个软件的生命周期中，80%的花费在于维护 * 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护* 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码 * 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品 1.2 开发规范的作用 * 减少维护花费 * 提高可读性 * 加快工作交接 * 减少名字增生 * 降低缺陷引入的机会

2 命名规范 2.1 常量命名规范 2.1.1 类型 常量命名规范 2.1.2 说明 常量用于保存需要常驻内存中并且经常使用变化不多的数据，定义常量的名称的时候需要遵循望文知意的原则； 2.1.3 规则 1.全部为大写字母； 2.中间以“_”连接； 3.望文知意原则； 2.1.4 备注 代码中涉及到直接使用某个字符串或者其他基本类型的值时，建议定义成常量，避免多处直接使用同样的值作为参数。 2.1.5 举例 ?如：定义一个常量表示最小屏幕宽度的常量，则可以定义一个int类型的常 量，该常量可以命名为：“MIN_SCREEN_WIDTH“； ?其他举例： ?例如：static final int MIN_SCREEN_WIDTH = 4；( √) ?例如：static final int min_screen_width = 4;（×） ?例如：static final int minScreenWidth = 4; （×） ?例如：static final int WIDTH = 4；（×）

产品使用说明书编写规定

产品使用说明书编写规定 1本标准规定了产品使用说明书的基本要求和编写方法。 本标准适应于湖北京山轻工机械股份有限公司产品使用说明书的编写。 2引用标准 下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。 GB9969.1 工业产品使用说明书总则 JB/T5995 工业产品使用说明书机电产品使用说明书编写规定 3基本要求 3.1当需要时必须编制产品使用说明书，使用说明书是交付产品的组成部分。 3.2使用说明书的开本幅面采用16开，大于16开的幅面应折页成16开。多页应装订 成册。 3.3使用说明书可按产品型号编制，也可按产品系列编制。复杂产品和成套设备可按功 能单元、整机分别编制使用说明书，再按产品型号、用途组合成系统的使用说明书。 3.4使用说明书应对涉及安全方面的内容给出安全警告。安全警告的内容应用较大的字 号或不同的字体表示，或用特殊符号或颜色来强调。使用说明书必须按下列等级和警告用语提醒用户： —“危险”表示对高度危险要警惕； —“警告”表示对中度危险要警惕； —“注意”表示对轻度危险要关注； 3.5使用说明书应明确给出产品用途和适应范围，并根据产品的特点和需要给出主要结 构、性能、型式、规格和正确吊运、安装、使用、操作、维修、保养等的方法，以及保护操作者和产品的安全措施。 3.6使用说明书内容的表述要科学、合理、符合操作程序，易于用户快速理解掌握。3.7对于复杂的操作程序，应多采用图示、图表、和操作程序图进行说明。 使用说明书中的图、表应和正文印在一起，图、表应按顺序编写序号。 3.8具有几种不同和独立功能的产品的使用说明书，应先介绍产品的基本的和通常的功 能，然后再介绍其他方面的功能。 3.9使用说明书应尽可能设想用户可能遇到的问题，并提供预防和解决的办法。 3.10应使用简明的标题和标注，以帮助用户快速找到所需内容。 3.11使用说明书应将机、电、气、液等融合一起编制，不能各行其是。 3.12外购件的使用说明书应附在相应的产品使用说明书上。编制产品使用说明书时，除 在产品使用说明书中简述其使用、操作方法外，还应注明详见某某使用说明书。 3.13使用说明书中的符号、代号、术语、计量单位应符合最新发布的国家法令、法规和 有关标准的规定，并保持前后一致。 3.14当产品结构、性能等改动时，使用说明书的有关内容必须按规定程序、及时作相应 修改。 4基本内容 4.1封面 封面一般应包括：产品型号、名称、使用说明书字样。 4.2次页

代码规范

目录 一．规范简介 1.1 目的 所有的程序开发手册都包含了各种规则。一些习惯自由程序人员可能对这些规则很不适应，但是在多个开发人员共同写作的情况下，这些规则是必需的。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。 本规范正是为培养规范设计和编程，养成良好的习惯，增强软件产品的稳定，健壮，可靠性；同时也为了提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的规范。 1.2 开发规范的重要性 （1）减少维护成本； 一个软件的生命周期中，80%的花费在于维护，另一方面，几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，规范的编码减少人员变动带来的维护成本。 （2）改善软件的可读性 可以让程序员尽快而彻底地理解新的代码。在一个团队中，代码也容易在程序员之间共享。 （3）维护部门交付产品的规范形象。 二．具体规范 2.1 注释 注释是软件可读性的具体表现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，要精确表达出程序的处理说明。避免每行程序都使用注释，可以在一段程序的前面加一段注释，具有明确的处理逻辑。 注释必不可少，但也不应过多，不要被动得为写注释而写注释。

2.1.1 需要注释的部分 （1）文件头注释，文件创建及修改记录，版权归属，作者以及修订者，以及对文件的简短描述。 （2）类的目的（即类所完成的功能）、设置接口的目的以及应如何被使用。 （3）成员方法注释（对于设置与获取成员方法，在成员变量已有说明的情况下，可以不加注释；普通成员方法要求说明完成功能，参数含义以及返回值）。 （4）普通成员方法内部注释（控制结构、代码所起到的作用以及如此编写代码的原因，处理顺序等）。 （4）参数的含义以及其他任何约束或前提条件、字段或属性描述。而对于局部变量，如无特别意义的情况下则不加注释。 2.1.2 具体注释 （1）文件头注释 要求：遵循JavaDoc的规范，在每一个源文件的开头注明该文件的作用, 作简要说明, 并写上源文件的作者,版权信息编写日期。如果是修改别人编写的源文件，要在修改信息上注明修改者和修改日期。 例子： /** * @Title: 文件名 * @Copyright (C) 年份龙图软件 * @Description: 文件信息描述 * @Revision History: * @Revision 版本号日期作者. */ （2）类和接口的注释 要求：遵循JavaDoc的规范，在每一个类的开头注明该类的作用，作简要说明，并写上作者，编写日期。 例子： /** * @ClassName: 类（或接口）名 * @Description: Description of this class

信息技术有限公司代码开发规范

xx信息技术有限公司代码开发规范 xx信息技术有限公司

代码开发规范 一、项目： IDE统一采用MyEclipse： 1.Tab policy设为“Spaces only”，Indentation size、Tab size均设为4 2.Maximum line width设为：140 3.java文件进行自动格式化 4.项目编码utf-8 二、代码： ?原则 1.数据结构应该只有公共变量；对象应该只有私有变量和公有函数； 2.一个类只做一类事、一个方法只做一件事 3.类、方法尽量简单、短小 4.宽度不超过140个字符 5.方法不超过40行，基本一屏高度 6.类不超过500行 7.尽量用好的命名代替注释 ?基本 1.统一采用log4j代替System.out.print、e.printStackTrace()等打印方式 2.流程语句必须用大括号 3.IO流必须用try finally关闭 ?命名 1.java基本命名规范 2.类为名词、属性为名词、方法为动词(+名词) 3.可以用2代替to，用4代替for，如string2int() 4.命名不许相互包含，如：get()，getOne()

5.不要采用getModel()、getModel1()、getModel2()数字方式命令 ?类型 1.对象属性必须为类，不能用String代替Number、Date等，不能使用基 本类型； 2.方法参数、返回均不许为Map（除非dao层） 3.泛型必须注明类型、不许使用List