工作文档编写_规范_V1.1

工作文档编写规范

王仁飞V1.1

1. 概述

俗话说：国有国法，家有家规。作为一个企业，文档的编写也应有相应的规范。统一、整齐、美观的文档格式代表着企业的形象，工作的态度。形式上的统一，对内容的完整性将更有保障，也更方便对文档的浏览。

工作文档是用来组织工作的，不只是用于自己工作的组织，更多的是用于协调。在编写文档的时候，要时刻不忘，如何让别人花更少的时间，获得他最想要得到的信息，这是文档编写的要旨。

2. 文档编写

2.1 文件名命名

2.1.1 通用要求

为了实现对文件的快速、准确定位，所有的文件取名要求清晰、有意义，能简要说明文件内容。文件名由有意义的字段构成，每个字段之间使用下划线“_”连接。例如：“20050405-0407_WSTSC检测_王仁飞”。

对于可以使用时间进行定位的文档，例如投标书，要附上时间，采用yyyymmdd 的格式；对于可能被升级、更新的文档，例如常见问题，使用说明书，使用版本号进行版本控制，文件名必须包含版本号。

版本号前加“V”，后面数字表示发布版本号；版本号后加“x”表示仍在编辑中的文件，或者尚需探讨的文件。如：工作文档编写_规范_V0_王仁飞。

对于被更新、被升级的文档，需要在最后增加“修订历史”作为文档历史更新依据。

2.1.2 工作计划类文件名

时间（计划所涵盖工作的起止时间）_计划名称_计划编写人

如：20050601-20051231_2005年度工作计划_过建辉

2.1.3 工作总结类文件名

时间（总结所涵盖工作的起止时间）_工作内容_总结编写人

如：20050405-20050407_WSTSC检测_王仁飞

2.1.4 投标书文件名

投标日期_标的业主名_标的名称_“投标书”

如：20050405_昌飞_西苑小区工程动力设备_投标书

2.1.5 标的原材料统计文件名

标的（或项目）日期_标的（或项目）名称_“材料统计”

如：20050404_昌飞_动态无功补偿_材料统计

2.1.6 标的存档类图纸、技术文件命名

标的（或项目）日期_标的（或项目）名称_相关关键词

如：20050404_昌飞_动态无功补偿_设计方案

2.1.7 规范、技术开发类文件命名

规范（或技术）_规范（或常见问题、维修文档等）_版本号

如：工作文档编写_规范_V0

凡修订者和作者不是同一个人的，先征得作者同意再作相应的修订。

2.2 文档内容

2.2.1 通用要求

文档内部的题目下，如果是不被更新的文档，必须要有作者项，其中包含如下要素：作者，编写日期；如果是可更新属性的文档，必须包含版本历史，包含如下要素：时间、修订者、位置、修订内容，以及版本号、修订源、主编、发布时间，如果是正式发布版本，还需包含发布时间。

2.2.2 工作计划

计划包括两个部分：现状分析——开展计划的必要性、充分性以及预期达到的目的；计划内容——实施计划的步骤以及需要的资源等。

凡是需时超过一个星期或者需要其他人配合的工作，都需要预先提交工作计划，以便备案。工作计划的编写要具备可考核性，要明确考核指标，不能使用模糊字眼，例如“尽量”、“尽快”。

对于大型项目的工作计划，需要细化、明确到每一个步骤预期完成日期，以及相应的人员工作计划。小项目的工作计划可以从简，写出预期目的，与预期完成时间。

2.2.3 工作总结

总结涵盖三个部分：过程记录——用于记录原始素材；结论分析——用于记录工作结论；工作总结——记录个人工作过程的失误、体会、可以改进提高的地方。

其他人员（非作者）可以根据需要，直接浏览相应的部分。检查任务执行过程，可以看过程记录；需要调阅工作的成果，可以只看结论分析；新人学习工作的过程，可以进一步看工作总结，避免被同一块石头绊倒。

总结应该在完成工作后尽快编写，因为时间拖得越长，很多细节就会忘掉越多。

2.2.4 规范章程

规范章程类包括两个部分：概要——制定本规范章程的目的、意义以及适用范围；具体规范——规范章程的主体；技术手段——规范章程实施技术保障手段。

2.2.5 说明书

说明书类文档是写给用户看的，编写应该围绕这个宗旨。

3. 使用word编写文档

3.1 word屏幕介绍

word的屏幕从上到下，分别由标题栏、主菜单栏、常用工具栏、格式工具栏。

这里特别要强调的是主菜单栏中，“插入”下拉菜单中常用的是“题注”、“交叉引用”、“索引与目录”、“图文框”；“格式”下拉菜单中常用的是“字体”和“段落”、以及下面十分强调的“样式”。特别要注意的是主菜单中“格式”下拉菜单中的“字体”与“段落”是用来调整个别段落和字体用的，对应于格式工具栏中的第二与第三项内容。而在word的“样式”菜单中的“字体”与“段落”菜单对应的是全篇论文的统一格式对应于格式工具栏中的第一项。也就是说，格式工具栏中的第一格中下拉菜单将给出正在使用的具体的格式，是具体样式的“样式库”。通过选择该栏中的样式可以定义文中的格式。选中某个段落后，再通过该栏中选择一个“样式”，该段落即会改变成所选中的“样式”所定义的格式。

3.2 使用“样式”

要有效使用word软件，样式是word处理文档的一个主要手段。使用word来处理文档，又不使用“样式”的话，那么不算会使用word。

3.2.1 什么是样式？

“样式”事实上是一个工具，这个工具一经确定以后，那么在文档输入中，这个工具将一直保证文档在任何地方都将用完全一致的方式来实现对各级标题、正文、附注、参考文献、图注、表头等格式的完全一致，从而至少在格式上使文档达到完美。

3.2.2 哪里有“样式”

在主菜单的“格式”中下拉，可以发现“样式”一栏，点击后会出现“样式”面版。在这个“样式”面版中可以进行以下操作：

在“样式类型”一栏中选择“所有样式”；

在“样式”中有各种各样的条目：标题1、标题2、一直到标题9，其他如正文、页眉等等。

“管理器”按钮在点击后可以进入管理器对本文档所需要的样式进行管理。

“新建”、“更改”按钮：“新建”可以实现特定的“样式”定义，“更改”则用于建立自己的风格。一般而言，不需要应用这两个功能，因为过多的超越了定义样式之外的东西会让企业文档风格不统一。

3.2.3 工作文档需要那些“样式”

我们的工作文档，根据文档类型、阅读对象的不同可使用如下格式的样式模板，如果已有样式模板不适用正在编写的文档，可以制作一个新的样式模板。并在申报通过后，予以共享使用。

1．工作报告模板

2．工作总结模板

3．技术文档模板

4．传真文档模板

3.2.4 怎样将格式应用到文档中

一种方法是将各种样式定义完后，输入时直接按照这种样式进行。

另外一种方法，按照“正文”样式输入，然后将该段文字选中后，在格式栏中的第一项中选择需要的“样式”名称。

有的时候，由于Office软件本身的问题，文档的格式可能会乱掉。这个时候不要急着去修改样式，简单的把文档关闭，重新打开一下。

3.3 关于使用“编号项”、“题注”和“交叉引用”

在文档撰写中图表的管理的难度在于，修改了文档以后，其编号将出现混乱。为了避免这一点，必须使用“列表编号项”、“题注”样式，同时学会怎样使用“交叉引用”。

列表编号项对参考文献特别有用，把参考文献部分按照“列表编号项”样式设置。然后在需要引用该参考文献时候，在引用处利用主菜单中的“插入”下拉菜单中，选中“交叉引用”，出现“交叉引用”面版后，选择编号项，将出现所有编号的内容，这时选中要引用的文献，并且选“只有编号”。那么参考文献的编号就会出现在插入的地方。

“题注”样式则十分适合图注与表注的编号。在表的上方或图的下方，从主菜单中的“插入”下拉菜单中，选择“题注”菜单。在“题注”面板上，可以选择标签一栏中的“图”或“表”作为标签。如果没有“图”或“表”的标签，则可以选择“新建标签”按钮，新建一个“图”标签或“表”标签。一旦插入后，那么图表将完全顺序编号。如果在文中要提及图或表，那么可以用上述的“交叉引用”方法

插入。

一旦“交叉引用”实现，那么交叉引用点与图表将建立链接关系，如果图表由于修改而变化，那么引用点将自动变化。

3.4 一些忠告和word使用中的小窍门

1．忠告：利用另外文件写作论文摘要，原因是同一文件处理可能在页码编制上会遇到问题。

2．忠告：word中不要用空格键来留空，特别是试图让文档对齐时。解决方案：一是利用“格式”栏中的分栏工具；二是用表格，然后隐去表格线。

3．忠告：使用主菜单中“插入”下拉菜单中的“图文框”。在使用word中，一个十分棘手的问题是图的插入。请仔细研究图文框的各项选项，就会发现确定利用插入图文框，然后定义该图文框的大小尺寸和在文章中的具体位置是十分方便的。

4．忠告：宁可使用剪贴方法来处理图，在图文框中留以一致的大小尺寸；否则文件太大，难以操作。使用图文框的一个主要难点是往往这一页空一大截，可是下一页的段落怎么也填补不到这一页。问题在于图文框是与这一段文字链接在一起的。当点击激活图文框时，将会看到该段落首字或回车符上有一个上锁或未上锁的“锚”样的标记，当图文框加上这段文字超过上页的空白空间，那么自动一起下移到下一页。

5．忠告：如果要让下一页的文字来填补这页空白，那么必须将该段文字与图文框链接的“锚”移掉。在移动锚前，必须在“图文框格式”菜单中，选择“随文字移动”，而不能使用固定位置。否则不能移动“锚”。“图文框格式”

菜单的弹出请将图文框击活，然后按鼠标的右键即可。

6．忠告：要认真学会使用word所带的表格，使用表格的工具栏可以让很方便地制作表格。需要注意的是表格里的文字材料都可以用主菜单中“格式”中的“段落”来控制。需要强调的是文字在表格中的上下居中，在表格工具栏中有专门的按钮来实现。

7．以上只是word使用的一小部分，有更多的东西尚需进一步的学习。

3.5 文档审查的重点

1．文档审查的第一步是格式，是否严格符合规范的要求；

2．文档审查的第二步是错别字；

3．文档审查的第三步才是内容部分。

由于文档格式的混乱，将给所有调阅文档的人带来麻烦，浪费了宝贵的工作时间，因此格式是首位的；同时，大量错别字的文档反映的是企业及人员素质的低下，从企业形象的角度出发，错别字检查排在第二位；文档的内容反映了编写者的工作，用于考核其工作成果，反映其工作的能力，是需要逐渐积累的。

4. 版本历史

代码编写规范

知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了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）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。

程序代码注释编写规范

程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在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:

产品说明书和用户文档集撰写要求概论

附件4：产品说明的提交要求 说明：红字条款可根据软件产品实际情况进行剪裁，黑字条款为标准要求必须说明的项目。斜体字是对国家标准条款的解读或举例，仅供使用者参考。 一、产品说明： 【定义】 陈述软件各种性质的文档，目的是帮助潜在的需方在采购前对该软件进行适用性评价。 解读：产品说明为供方在进行产品销售时对产品性质的宣传资料，目的是让采购方获得产品概况，判断该产品是否能够满足自己的需求，进而决定是否采购该产品。 【要求】 产品说明对于需求方是可用的，包含潜在需方所需的信息，信息内容应排除内部的不一致，且与用户文档集和软件实际情况一致，产品说明的内容应该是可以验证或测试的，产品说明应有唯一性标识，当产品说明内容超出一页文档时，要有封面和目录，方便使用者进行内容查找。 【内容】 1、软件产品应以其名称、版本和日期指称； 解读：软件产品要用名称+版本或名称+日期命名。 例如：城市水资源管理系统软件V1.0或城市水资源管理系统软件2011。 2、产品说明应显示唯一的标识； 解读：产品说明在封面或卡片的显著位置显示唯一的产品标识。 例如：城市水资源管理系统软件V1.0产品说明。 3、产品说明应包含供方和至少一家销售商（当适用时）电子商务销售商或分销商的名称和地址（邮政的或网络的）。 解读：产品说明在封面或卡片的显著位置显示供方和销售商信息一般包括名称和地址，且供方和销售商可以为同一企业或个人。 4、产品说明应标识该软件能够完成的预期的工作任务和服务； 解读：此项描述软件的销售方向，适用的行业，潜在的客户群，概要介绍软件的用途。

例如：本软件为水务行业管理软件，适用于各供水公司、净水厂、水污染处理企业、政府水资源行业管理部门，可完成水资源相关业务的管理及实施对水资源处理装置的动态监控和实时处理。 5、供方想要声称软件产品符合由法律或行政机构界定的要求时，产品说明应标识出这些法律或行政机构界定的要求的需求文档； 解读：供方为加大产品的宣传力度，增强产品竞争力，更好的销售其软件产品，可表明其产品符合法律或行政机构界定的要求。但必须将符合的内容在产品说明中进行详细说明。 例如：本软件符合中华人民共和国水利行业标准SL475-2010水利信息公用数据元标准，该标准的详细信息参见附录一 6、产品说明应以适当的引用文档指名产品在何处依赖于特定软件和（或）硬件；解读：当产品在某些情况下需要依赖于特定的软件和（或）硬件才能实现其生成的产品性质时，要对这些特定的软件和（或）硬件进行描述，以便采购方在采购产品时能够合理评价采购成本。 例如：本软件在对水资源处理装置进行远程动态监控及实时处理时如传输距离超过50米需要信号放大器或无线信号发射器与无线信号接收器 7、产品说明引证已知的对其他软件的用户可调用的接口时，应标识出这些接口或软件； 解读：如果软件再使用过程中需要调用其他软件许可的接口时，应说明这些接口或软件从而使采购方在选择该产品时，明确还需购买其他接口许可或软件。 例如：本软件运行时需要调用水资源信息实时处理业务系统V1.0 8、产品说明应指明产品期望在单一系统上供多个并发最终用户使用或供一个最终用户使用，并且应说明在所要求的系统的所陈述的性能级别上可行的最大并发最终用户数； 例如：当软件支持并发时，此处可进行如下类似描述：本软件在单一系统上可供多个并发最终用户使用，在服务器主频大于3.0GHZ、内存大于2GB、响应时间小于5秒的情况下最大100并发最终用户。 当软件不支持并发时，此处可进行如下类似描述：本软件在单一系统上只供一个最终用户使用，不支持并发操作。

文书撰写工作规范.doc

文书撰写工作规范 为进一步规范中心文书撰写工作质量，有效提高工作效率，现拟定中心工作人员常用的工作计划、工作总结、调查报告、业务技术指导书及检验报告等文书撰写规范，请全体人员遵照使用，并纳入年度科室工作质量考核和个人技术晋升聘用考核内容。 一、各类常用文书内容规范要求 (一)工作计划 计划是行动的先导。工作计划则是工作之前用文字形式拟定的工作内容和步骤。工作计划一经讨论通过，一般作为通知的附件下发（或科室作为材料上报中心），对本部门或本科室的工作具有权威性和约束力。 1.计划种类 常见有规划、设想、计划和安排打算等等。 规划属于轮廓式的，时间跨度比较长，一般设定在三五年以上；设想属于粗线条的，非正式的计划；计划则比较深入和细致；同计划相比，安排、打算的时限更短，内容更为集中和具体。 2.撰写规范 计划内容的表述形式主要有条文式和表格式两种。 常见条文式计划的写法规范为： (1)标题：通常包含单位（科室）名称、时限、内容、文种名称等四项。这四项的顺序不能颠倒，时限应写全称，内容应简明，使之一目了然。如“合肥市疾病预防控制中心二〇〇六年工作计划”、“免疫规划科二〇〇六年工作计划”。标题字数过多的，标题中可考虑不写单位（科室）名称，但就必须在落款时书写单位（科室）名称。 (2)正文：内容繁简不同，但必须包括“做什么、怎样做、什么时候做完”等三个要素。 正文开头一般应提出总的任务和要求，说明“做什么”（有的还要说明为什么要这样做和能不能这样做，以加强执行计划的信心和决心），任务和要求必须具体，能量化的必须量化。。 提出总体任务和要求之后，就要分块或分条列项，把总体任务分解到有关部门（小组）或人员，并且根据实际需要或详或略地交代完成任务的步骤、方法、政策精神，提出时间要求。这就是谁去做、怎样做、什么时候做完。 (3)结尾：结尾有时要有几句概括认识、表示决心的话，有时意尽则止。 计划末尾要有落款，写明制订计划的单位和时间（标题列入单位名称的可直接落款时间）。 3.撰写中应注意的问题 常见有些计划虽然提出了任务，但没有将任务分解到具体的部门（小组），有时只讲“群策群力”、“广泛发动干部群众”之类的套话；或者提出了任务，而没有交代方法、步骤与时间要求，这样的计划往往容易落空。不解决“谁去做”、“怎样做”、“什么时候做完”，计划就会流于形式。 (二)工作总结

程序代码注释编写规范

百度文库- 让每个人平等地提升自我 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() */ 意:与溢出中断写初值不同}

PHP代码编写规范

QC 质量管理体系文件 代码编写规范 受控状态：■受控□非受控 发布日期：2006年02月20日 实施日期：2006年02月24日

1. 引言 1.1. 目的 制定本规范是为了能达到以下目的： ●提高程序员工作效率和代码的利用性 ●程序员可以了解任何代码，弄清程序的状况 ●新人可以很快的适应环境 ●防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯 ●防止新接触php的人一次次的犯同样的错误 ●在一致的环境下，人们可以减少犯错的机会 1.2. 适用范围 适用于本公司的所有开发人员，包括数据库、网页及应用程序开发人员，及有关的程序测试人员。 1.3. 引用标准 GB/T 8566-1995 信息技术软件生存期过程 GB/T 8567-1988 计算机软件产品开发文件编写指南 1.4. 术语 GB/T 11457-1995中所使用的术语适用于本规范。

2. 代码编写规则 2.1. 注释 （1）编写代码期间注释要求占程序总量15%以上。 （2）每个模块顶部必须说明模块名称、功能描述、作者等。 （3）每个过程、函数、方法等开头部分必须说明功能、参数、返回值、原数据和目标数据数据结构等等。 （4）变量定义的行末应当对变量给出注释。 （5）程序在实现关键算法的地方应当给出注释 2.2. 变量、函数、过程、控件等命名规则 （1）变量命名采用[作用范围][数据类型][自定义名称]规则定义，要求看到变量名就能直观的看出其范围和数据类型。 （2）函数、过程、方法、事件等命名应尽量做到观其名知其义。 （3）控件的命名采用[控件类型][自定义名]规则定义,要求通过名字能直观看出控件类型。 （4）自定义命名空间规则，要求能顾名思义 2.3. 源代码规则 风格约定：采用缩进的格式保存程序的层次结构。要求能直观的看出循环、判断等层次结构。

文档编写规范-模板

XXX有限公司文档编写规范

*变化状态：A——增加，M——修改，D——删除

目录 前言................................................................................................................................................................ - 4 -第1章（居中/二号/宋体/TIMES NEW ROMAN/加粗/另起一页）................................................... - 5 - 1.1 （偏左/三号/黑体/Arial/加粗） ............................................................................................ - 5 - 1.1.1 （偏左/三号/宋体/Times New Roman/加粗）........................................................... - 5 - 1.1.1.1 （偏左/四号/黑体/Arial/加粗） ...................................................................... - 5 -

前言【本部分可以有，也可以没有，根据实际情况自定】时间:2010-12-15

第1章（居中/二号/宋体/Times New Roman/ 加粗/另起一页） 1.1 （偏左/三号/黑体/Arial/加粗） 【具体内容】 1.1.1 （偏左/三号/宋体/Times New Roman/加粗） 【具体内容】 1.1.1.1 （偏左/四号/黑体/Arial/加粗） 【具体内容】 贴图格式（居中） 序号格式 1. ● ● ● 2. 3.

GBT1.1 -2009 标准化工作导则 第1部分：标准的结构和编写(摘要)

GB/T 1.1-2009 标准化工作导则第1部分：标准的结构和编写（摘要） 6.1.1 封面 封面为必备要素，它应给出标示标准的信息，包括：标准的名称、英文译名、层次（国家标准为“中华人民共和国国家标准”字样）、标志、编号、国际标准分类号（ICS号）、中国标准文献分类号、备案号（不适用于国家标准）、发布日期、实施日期、发布部门等。 如果标准代替了某个或几个标准，封面应给出被代替标准的编号；如果标准与国际文件的一致性程度为等同、修改或非等效，还应按照GB/T 20000.2的规定在封面上给出一致性程度标识。 标准征求意见稿和送审稿的封面显著位置应按附录C中C.1的规定，给出征集标准是否设计专利的信息。 6.1.2 目次 目次为可选要素。为了显示标准的结构，方便查阅，设置目次是必要的。目次所列的各项内容和顺序如下： a) 前言； b) 引言； c) 章； d) 带有标题的条（需要时列出）； e) 附录；

f) 附录中的章（需要时列出）； g) 附录中的带有标题的条（需要时列出）； h) 参考文献； i) 索引； j) 图（需要时列出）； k) 表（需要时列出）； 目次不应列出“术语和定义”一章中的术语。电子文本的目次应自动生成。 6.1.3 前言 前言为必备要素，不应包含要求和推荐，也不应包含公示、图和表。前言应视情况依次给出下列内容： a)标准结构的说明。对于系列标准或分部分标准，在第一项标准或第1部分中说明标准的预计结构；在系列标准的每一项标准或分部分标准的每一部分中列出所有已经发布或计划发布的其他标准或其他部分的名称。 b)标准编制所依据的起草规则，提及GB/T 1.1。 c)标准代替的全部或部分其他文件的说明。给出被代替的标准（含修改单）或其他文件的编号和名称，列出与前一版本相比的主要技术变化。 d)与国际文件、国外文件关系的说明。以国外文件为基础形成的标准，可在前言中陈述或相应文件的关系。与国际文件的一致性程度为等同、修改或非等效的标准，应按照GB/T 20000.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. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************

文件编写规范

密级：内部公开 文档编号： 版本号：V1.0 分册名称：第1册/共1册 文件编写规范 xxx科技有限公司 编制：生效日期： 审核：批准：

文件更改摘要 日期版本号修订说明修订人审核人批准人

目录 1.目的和范围 (4) 2.目标 (4) 3.术语表 (4) 4.文档编号规则 (5) 5.文档命名规范 (5) 6.文件结构规定 (6) 7.封面 (7) 8.修订页 (8) 9.正文内容格式 (8) 10.文件版本号和文件命名规定 (9) 10.1.文件版本号规定 (9) 10.2.文件命名规定 (9)

1.目的和范围 ●背景说明：本文件作为公司内部文档管理文件，所有公司内编写的文档，均应遵 守本规定，作为公司的所有文档编写统一要求。 ●范围：所有的CMMI执行过程中产生的文档，均应当执行本文件要求作为基础的要 求，如果该部分的体系文件存在明确的要求的，按照体系文件要求执行，没有的则按照本文件执行。 2.目标 规范和统一公司管理体系中所有相关文件的风格和样式，指导公司程序文件、模版文件以及各种记录文件的编写。 3.术语表 ●文件标识：文件的属性标志，包括文件名称、文件编号、版本、生效日期、 审批状态、密级等。 ●程序文件：描述为完成管理体系中所有主要活动提供方法和指导，分配具体的职责 和任务而定义的文件。 ●模版文件：为了使管理体系有效运行，组织统一设计的一些实用的表格和给出活动 结果的报告，规范记录组织的管理体系运行情况。 ●记录文件：简称记录，是组织根据设计的模版和体系要求，填写的表格或者给出活 动结果的报告，作为管理体系运行的证据。 ●修订页：记录文件的修订历史，所有程序文件、除了表格以外的模版和记录都需要 有变更履历，一般位于程序文件的第二页。 ●文档密级：指本文档的保密程度，共分绝密、机密、秘密、内部公开、公开五级制 度。 ●绝密：涉及公司与客户或上游供应商，下游分销商所签订相关的文档资料。仅 限于公司最高管理层及各资料所涉及的经过相应管理人员授权的相关人员查 阅。 ●机密：公司内部所相关的规章制度及技术规范，开发手册等；还有各项目开发 文档、管理文档及软件产品等仅供相关部门高级领导以及经过授权后相关人员 查阅。 ●秘密：需交付用户或与客户进行交流的文档与产品，可供相关项目客户查阅。 ●内部公开：内部不限制，公司内部任何可以任何形式获得文档的信息并阅读、 保存、修改后自用等等，但是不允许向外传播的文件。 ●公开：项目组开发过程中的自用文档或面向售前工作的部分项目介绍材料等。 ●版本标识：作为文档的版本区分。所有发布版本之前不得大于1.0，发布版本作为 1.0，而其后只有重大修改可以调整小数点前的版本号，局部修改调整小数点后版

Java代码编写规范(参考)

命名规范： 1.所有的标识都只能使用ASCII字母（A-Z或a-z）、数字（0-9）和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词，采用大小写混合的方式，每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组，采用大小写混合的方式，第一 个单词的首字母小写，其后单词的首字母大写。 6.变量名的第一个字母小写，任何中间单词的首字母大写，变量名 应简短且可以顾名思义，易于记忆。避免单个字符的变量名，除非是一次性的临时变量。 7.常量的声明应该全部大写，每个单词之间用”_”连接。 注释规范： 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/，而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释，其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释（main除外）。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。

缩进排版规范： 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范： 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范： 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范： 1.每行至少包含一条简单语句。 2.在return语句中，返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中，避免因使用3个以上变量， 而导致复杂度提高。 5.当switch的一个case顺着往下执行时（因为没有break），通常 应在break语句的位置添加注释。

需求分析规范——附加说明1用例描述文档编写规范

百度文库 - 让每个人平等地提升自我 需求分析规范 用例描述文档编写规范（精要） 版本 <> 文档编号：001-0002-2

版本历史 日期版本描述作者2006-07-01 <> 初稿整理吕春秋

目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作描述的建议9 4.业务规则的描述9 4.1业务规则的种类9 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1子用例的设计方法13 5.2子用例中判断上级调用用例的方法13 6.用例描述中的其它规范14 6.1类、属性、参数、值的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3描述一致性15 7.接口15 8.新一代ERP系统中的几个公共机制15

8.1删除完整性检查15 8.2消息机制16 8.3编号管理16 9.用例描述中用词规范16 9.1范围值的描述16

制度编写规范标准[详]

制度编写规 第一条本规适用于公司所有单体制度。制度起草时须严格遵循规进行起草，公文印发时的制度附件也须符合本规。 制度汇编或单行本的印刷版式、打印设置、装订要求须遵照公司的印刷要求进行排版、印刷、装订，此处不另行规。 第二条制度编写总体要求 （一）依法合规：制度应正确体现法律法规、相关政策及公司上位制度要求，不得与上述规性文件存在矛盾或冲突； （二）全面具体：制度应将所涉及到的业务逐一阐明，制度容尽量细化，明确流程，体现闭环管理的思想。对所规定的适用围、操作步骤、评价标准等要具体、明确； （三）严谨规：制度撰写时应严格依照制度模板进行撰写，符合格式规。制度的行文用语应尽量准确，不使用弹性语言和模糊性描述。 第三条制度标题规 （一）制度统一按照“适用围+制度容+体现制度属性的名称”进行命名。“适用围”是指该制度施行时所涵盖的围，一般使用简称，如“国能集团”等；“制度容”是指该制度

针对哪些容做出了规，如“电力安全管理”等；“体现制度属性的名称”指基于制度属性对该制度的命名，如“章程”、“规定”、“办法”、“细则”等。 根据属性，不同制度应使用不同名称。纲领类制度可使用章程、纲要；原则类制度可使用规定；实施类制度可使用办法、细则、规、守则、规则、预案。 （二）制度的“试行”、“暂行”等版本说明，以括号括起来放在标题下方。如无，则说明是正式版本。制度的生成和修订记录等修订历史信息应记录在《制度关键信息表》中，并于每次修订时更新。 第四条制度索引规 每项制度均应标注一个索引号，以便于未来的信息化管理。索引号的编排规则为：“SHZD 组织机构代码+发布年份+编号”，其中组织机构代码应能覆盖全公司，发布时间具体到年，编号为当年发布的所有制度按发布时间顺序排列的流水编号。如SHZD5100-2013-0001”。制度索引号是适用于公司全局的统一编码，由总部制度管理归口部门统一按照规则对单体制度编制索引号。

程序员代码编写标准指南汇总

Delphi 6 程序员代码编写标准指南 一、序言 二、通用源代码格式规则 2.1 缩格 2.2 页边空格 2.3 Begin…End 配对 2.4 代码文件中通用符号含义 三、Object Pascal 3.1 括号 3.2 保留字和关键字 3.3 过程和函数（例程） 3.3.1 命名/格式化 3.3.2 形式参数 3.3.2.1 格式化 3.3.2.2 命名 3.3.2.3 参数的排序 3.3.2.4 常量参数 3.3.2.5 名称的冲突 3.4 变量 3.4.1 变量的命名和格式 3.4.2 局部变量 3.4.3 全局变量的使用 3.5 类型 3.5.1 大写约定 3.5.1.1 浮点指针类型 3.5.1.2 枚举类型 3.5.1.3 变数和ole变数类型 3.5.2 结构类型 3.5.2.1 数组类型 3.5.2.2 记录类型 3.6 语句 3.6.1 if 语句 3.6.2 case 语句 3.6.2.1 一般性话题 3.6.2.2 格式 3.6.3 while 语句 3.6.4 for 语句 3.6.5 repeat 语句

3.6.6 with 语句 3.6.6.1 一般话题 3.6.6.2 格式 3.7 结构异常处理 3.7.1 一般话题 3.7.2 try…finally的使用 3.7.3 try…except的使用 3.7.4 try…except…else的使用 3.8 类类型 3.8.1 命名和格式 3.8.2 域 3.8.2.1 命名/格式 3.8.2.2 可视化 3.8.3 方法 3.8.3.1 命名/格式 3.8.3.2 使用静态的方法 3.8.3.3 使用虚拟/动态的方法 3.8.3.4 使用抽象的方法 3.8.3.5 属性存取方法 3.8.4 属性 3.8. 4.1 命名/格式 3.8. 4.2 使用存取的方法 四、文件 4.1 工程文件 4.1.1 命名 4.2 窗体文件 4.2.1 命名 4.3 数据模板文件 4.3.1 命名 4.4 远端数据模板文件 4.4.1 命名 4.5 Unit文件 4.5.1 通用Unit结构 4.5.1.1 unit的名字 4.5.1.2 uses子句 4.5.1.3 interface部分 4.5.1.4 implementation部分 4.5.1.5 initialization部分 4.5.1.6 finalization部分 4.5.2 窗体单元

软件需求说明书编写规范

{产品名称} 软件需求规格说明书 编写人： 编写日期：年月日

目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义（可选） (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制（可选） (3) 3.功能需求 (3) 3.1.功能划分（可选） (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求（可选） (4) 6.运行需求（可选） (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求（可选） (5) 8.特殊需求（可选） (5) 9.不确定的问题（可选） (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5)

1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的，指出预期的读者。】 1.2.产品名称 【本项目的名称，包括项目的全名、简称、代号、版本号。】 1.3.名词定义（可选） 【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介，包括： 1.本产品的开发意图、应用目标及作用范围。 2．概略介绍了产品所具有的主要功能。可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等。 3．说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图，或者方框图说明。】 2.2.运行环境 1.硬件环境： 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境： 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制（可选） 【说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性，即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分（可选） 【此部分从用户的角度描述将软件划分成不同的部分，并给出总体功能结构。对于复杂

工作标准编写模板(TDS)

Q/GDW06XXXX XX部门 XX岗位工作标准 XX县(市)供电公司发布

Q/GDW06XXXX 3XXXXXX-2008 目次 前言.................................................................................................................................................. I I 1 范围 (1) 2 规范性引用文件 (1) 3 职责与权限 (1) 3.1工作关系 (1) 3.2职责 (1) 3.3权限 (1) 4 岗位人员基本要求 (2) 4.1准入学历与专业 (2) 4.2专业技术职称 (2) 4.3工作经历 (2) 4.4工作能力 (2) 4.5基本技能 (2) 5 工作内容与方法 (2) 5.1标题名称 (2) 5.2标题名称 (2) 6 报告与记录 (2) 7 检查与考核 (2) 7.1考核权限 (2) 7.2考核依据 (3) 7.3考核内容 (3) 7.4考核指标 (3) 8 流程名称目录 (3) 8.1本岗位主办的主要流程目录 (3) 8.2本岗位参与的主要流程目录 (3) I

Q/GDW06XXXX 3XXXXXX-2008 II 前言 本标准为规范X X县（市）供电公司X X部门X X岗位工作而制定。 制定本标准的目的是为明确X X县（市）供电公司X X部门X X岗位工作要求和方法，规范工作行为，提高工作效率。 本标准由X X县（市）供电公司标准化委员会提出并归口。 本标准由X X县（市）供电公司标准化办公室组织起草编制。 本标准起草人：（署明起草人姓名） 本标准初（复）审人：（专业主管负责人） 本标准审定人：（专业分管领导） 本标准批准人：（标准化委员会主任） 本标准由X X县（市）供电公司标准化委员会委托X X 部门负责解释。 版次：A/0

安全代码编写规范

安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。

四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对