知识管理系统代码编写规范
一、介绍
本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。
本规范主要参考了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）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
注意：在使用Unicode码转义，或者甚至是有时直接使用Unicode字符的时候，添加一点说明注释将对别人读懂代码很有帮助。
三、源码文件结构
源码文件按照先后顺序，由以下几部分组成：
1. license 或者copyright 声明信息。（如果需要声明）
2. 包（package）声明语句。
3. import 语句。
4. 类声明（每个源码文件只能有一个顶级类）。
每个部分之间应该只有一行空行作为间隔。
3.1 license 或者copyright 的声明信息。
如果需要声明license 或copyright 信息，应该在文件开始时声明。
3.2 包声明
包声明的行没有行长度的限制。单行长度限制不适用于包声明。
3.3 import语句
3.3.1 不使用通配符import
即，不要出现类似这样的import语句：import java.util.*;
3.3.2 没有行长度限制
import 语句的行没有行长度的限制。单行长度限制不适用于import 语句所在行。
3.3.3 顺序和空行
import语句应该被分为几个组，每个组之间由单行的空行隔开。分组的顺序如下：
1. 所有的静态导入为归为一组。
2. com.sinosoft（项目自带包）包的import归为一组。
3. 第三方包。每个顶级包归为一组。第三方包之间按ASCII码排序。例如：
android,com,junit,org,sun
4. java包归为一组。
5. javax包归为一组。
同一组内的import语句之间不应用空行隔开。同一组中的import语句按ASCII 码排序。
3.4 类声明
3.4.1 只声明一个顶级类
每个源码文件中只能有一个顶级类。
例外：package-info.java，该文件中可没有package-info类。
3.4.2 类成员顺序
类成员的顺序对代码的易读性有很大影响，但这也不存在唯一的通用法则。不同的类可能有不同的排序方式。
重要的是，每个类都要按照一定的逻辑规律排序。维护者应该要能解释这种排序逻辑。比如，新的方法不能总是习惯性地添加到类的结尾，因为这样就是按时间顺序而非某种逻辑来排序的。
重载方法：不应该分开
当一个类有多个构造函数，或者多个同名成员方法时，这些函数应该写在一起，不应该被其他成员分开。
四、格式
术语说明：块状结构（block-like construct）指类、成员函数和构造函数的实现部分（大括号中间部分）。注意，在后面的节中讲到数组初始化，所有的数组初始化都可以被认为是一个块状结构（非强制）。
4.1 大括号
4.1.1 大括号不可省略
大括号一般用在if,else,for,do和while等语句。即使当它的实现为空或者只有一句话时，也需要使用。
4.1.2 非空语句块采用K & R风格
对于非空语句块，大括号遵循Kernighan & Ritchie风格：
?左大括号前不换行。
?左大括号后换行。
?右大括号前换行。
?如果右大括号结束一个语句块或者函数体、构造函数体或者有命名的类体，则右大括号后换行，否则不要换行。例如，当右大括号后面接else或者逗号时，不应该换行。
例子：
1.return new MyClass(){
2.@Override public void method(){
3.if(condition()){
4.try{
5. someting();
6.}catch(ProblemException e){
7. recover();
8.}
9.}
10.}
11.};
一些例外的情况，将在4.8.1节讲枚举类型的时候讲到。
4.1.3 空语句块：可以用简洁版本
一个空的语句块，大括号可以简洁地写成{}，不需要换行。如果它是一个多块语句的一部分(if/else或try/catch/finally) ，即使大括号内没内容，右大括号也要换行。
例子：
1.void doNothing(){}
4.2 语句块的缩进：4空格
每当一个新的语句块产生，缩进就增加两个空格。当这个语句块结束时，缩进恢复到上一层级的缩进格数。缩进要求对整个语句块中的代码和注释都适用。（例子可参考之前4.1.2节中的例子）。
4.3 一行最多只有一句代码
每句代码的结束都需要换行。
4.4 行长度限制：80或100
不同的项目可以选择采用80个字符或者100个字符作为限制。除了以下几个特殊情况外，其他代码内容都需要遵守这个长度限制。这在4.5节会有详细解释。
例外：
1. 按照行长度限制，无法实现地方（例如：Javadoc 中超长的URL 地址，或者一个超长的JSNI 方法的引用）；
2.package和import语句不受长度限制。（见
3.2、3.3节）；
3. 注释中的命令行指令行，将被直接复制到shell中执行的。
4.5 换行
术语说明：当一行代码按照其他规范都合法，只是为了避免超出行长度限制而换行时，称为长行断行。
长行断行，没有一个适合所有场景的全面、确定的规范。但很多相同的情况，我们经常使用一些行之有效的断行方法。
注意：将长行封装为函数，或者使用局部变量的方法，也可以解决一些超出行长度限制的情况。并非一定要断行。
4.5.1 在何处断行
断行的主要原则是：选择在更高一级的语法逻辑的地方断行。其他一些原则如下：
1. 在一个逗号后面断开。
2. 在一个操作符前面断开（= 号和foreach语句的冒号除外）。
3. 在调用函数或者构造函数需要断行时，与函数名相连的左括号要在一行。也就是在左括号之后断行。
4.5.2 断行的缩进：至少8个字符
当断行之后，在第一行之后的行，我们叫做延续行。每一个延续行在第一行的基础上至少缩进四个字符。
当原行之后有多个延续行的情况，缩进可以大于8个字符。如果多个延续行之间由同样的语法元素断行，它们可以采用相同的缩进。
4.6.3节介绍水平对齐中，解决了使用多个空格与之前行缩进对齐的问题。
4.6 空白
4.6.1 垂直空白
以下情况需使用一个空行：
1. 类成员之间需要空行隔开：字段、构造函数、方法、内部类、静态初始化语句块
（static initializers）、实例初始化语句块（instance initializers）。
2.
o例外：连续字段之间的空白行不是必需的。一般多个字段中间的空行，是为了对字段做逻辑上的分组。
3. 在函数体内，语句的逻辑分组间使用空行。
4. 类的第一个成员之前，或者最后一个成员结束之后，用空行间隔。（可选）
5. 本文档中其他部分介绍的需要空行的情况。（例如3.3节中的import 语句）
单空行时使用多行空行是允许的，但是不要求也不鼓励。
4.6.2 水平空白
除了语法和规范的其他规则，词语分隔、注释和Javadoc 外，水平的ASCII 空格只在以下情况出现：
1. 所有保留的关键字与紧接它之后的位于同一行的左括号（(）之间需要用空格隔开。
（例如if、for、catch）
2. 所有保留的关键字与在它之前的右大括号（}）之间需要空格隔开。（例如else、
catch）
3. 在左大括号（{）之前都需要空格隔开。只有两种例外：
4.
o@SomeAnnotation({a, b})
o String[][] x = {{"foo"}};
5.所有的二元运算符和三元运算符的两边，都需要空格隔开。一元操作符和操作数之间
不应该加空格，比如：负号(“-”)，自增(“++”)和自减(“--”)。例：i++;
6. 逗号、冒号、分号和右括号之后。
7. 如果在一条语句后做注释，则双斜杠(//)两边都要空格。这里可以允许多个空格，但没
有必要。
8. 变量声明时，变量类型和变量名之间需要用空格隔开：List
9. 初始化一个数组时，大括号之间可以用空格隔开，也可以不使用。（例如：int[] {5,
6}和new int[] { 5, 6 }都可以）
注意：这一原则并不要求或禁止一行开始或者结束时的空格。只针对行内部字符之间的隔开。
4.6.3 水平对齐：不做强制要求
术语说明：水平对齐，是指通过添加多个空格，使本行的某一符号与上一行的某一符号上下对齐。
这种对齐是允许的，但是不会做强制要求。
以下是没有水平对齐和水平对齐的例子:
1.private int x;// this is fine
2.private Color color;// this too
3.
4.private int x;// permitted, but future edits
5.private Color color;// may leave it unaligned
注意：水平对齐能够增加代码的可读性，但是增加了未来维护代码的难度。考虑到维护时只需要改变一行代码，之前的对齐可以不需要改动。为了对齐，你更有可能改了一行代码，同时需要更改附近的好几行代码，而这几行代码的改动，可能又会引起一些为了保持对齐的代码改动。这种改动，在最坏的情况下可能会导致大量的无意义的工作，即使在最好的情况下，也会影响版本历史信息，减慢代码review的速度，引起更多merge代码冲突的情况。
4.7 分组括号：建议使用
除非作者和代码审核者都认为去掉小括号也不会使代码被误解，或是去掉小括号能让代码更易于阅读，否则我们不应该去掉小括号。我们没有理由假设读者能记住整个Java运算符优先级表。
4.8 特殊结构
4.8.1 枚举类型
枚举常量间用逗号隔开，换行可选。
没有方法和文档的枚举类可写成数组初始化的格式：
例子：
1.private enum Suit{ CLUBS, HEARTS, SPADES, DIAMONDS }
枚举类型也是一个类（class），因此类的其他格式要求，也适用于枚举类型。
4.8.2 变量声明
每次声明一个变量
不要使用组合声明。例如：int a, b;
当需要时才声明，尽快完成初始化
局部变量不应该习惯性地放在语句块的开始处声明，而应该尽量离它第一次使用的地方最近的地方声明，以减小它们的使用范围。
局部变量应该在声明的时候就进行初始化。如果不能在声明时初始化，也应该尽快完成初始化。
4.8.3 数组
数组初始化：可写成块状结构
所有数组的初始化，都可以采用和块代码相同的格式处理。例如以下格式都是允许的：
1.new int[]{
2.0,1,2,3
3.}
1.new int[]{
2.0,
3.1,
4.2,
5.3
6.}
1.new int[]{
2.0,1,
3.2,3
4.}
1.new int[]
2.{0,1,2,3}
不能使用C风格的方式声明数组
方括号应该是变量类型的一部分，因此不应该和变量名放在一起。例如：应该是String[] args，而不是String args[]。
4.8.4 switch语句
术语说明：switch语句是指在switch大括号中，包含的一组或多组语句块。每组语句块都由一个或多个switch标签（case FOO:或者default:）打头。
缩进
和其他语句块一样，switch大括号之后缩进4个字符。
每个switch标签之后，新起一行，再缩进4个字符，后面跟着一条或多条语句。在标签结束后，恢复到之前的缩进，类似大括号结束。
fall-through注释
在switch语句中，每个标签对应的代码执行完后，要么通过break、continue、return或抛出异常来终止，要么通过注释说明代码将继续执行下一
个标签的代码。任何能表达这个意思的注释都可以（典型的是使用// fall through）。这个注释在最后一个标签之后不需要注释。例如：
1.switch(input){
2.case1:
3.case2:
4. prepareOneOrTwo();
5.// fall through
6.case3:
7. handleOneTwoOrThree();
8.break;
9.default:
10. handleLargeNumber(input);
11.}
标签需要显式声明
每个switch语句中，都需要显式声明default标签，即使它没有任何代码。4.8.5 注解（Annotations）
注解应用到类、函数或者构造函数时，应紧接Javadoc之后。注解独占一行。这里换行不属于长行换行(第4.5节，长行换行)，因此缩进级别不变。例如：
1.@Override
2.@Nullable
3.public String getNameIfPresent(){...}
例外：
如果注解只有一个，并且不带参数。则它可以和类或方法名放在同一行。例如：
1.@Override public int hashCode(){...}
注解应用到字段时，也是紧接Javadoc之后。不同的是，多个注解可以放在同一行。例如：
1.@Partial@Mock DataLoader loader;
对于参数或者局部变量使用注解的情况，没有特定的规范。
4.8.6 注释
语句块的注释风格
注释的缩进与它所注释的代码缩进相同。可以采用/* ... */进行注释，也可以用// ...进行注释。当使用/* ... */进行多行注释时，每一行都应该以* 开始，并且* 应该上下对齐。注意文字和注释符之间有一个空格（4.6.2水平空白）。
例如：
1./*
2. * This is // And so /* Or you can
3. * okay. // is this. * even do this. */
4.*/
提示：多行注释时，如果你希望集成开发环境能自动对齐注释，你应该使用
/* ... */，// ...一般不会自动对齐。
4.8.7 修饰符
多个类和字段的修饰符，按《Java Language Specification》中介绍的先后顺序排序。具体是：
1.public protected private abstract static final transient volatile
synchronized native strictfp
4.8.8 数字型的字面值
long类型的字面值使用大写L为后缀，永远不要使用小写l（避免和1混淆）。例如：
五、命名
5.1 适用于所有命名标识符的通用规范
标示符只应该使用ASCII字母、数字，字母大小写敏感。因此所有的标示符，都应该能匹配正则表达式\w+。
标示符不需要使用特殊的前缀或后缀，如name_，mName，s_name 和kName，在Java编程风格中都不再使用。
5.2 不同类型的标示符规范
5.2.1 包名
包名全部用小写字母，将各单词简单地连在一起（不使用下划线）。例如：，不要使用或。
5.2.2 类名
类名都以UpperCamelCase风格编写。
类名一般使用名词或名词短语，例如：Character或ImmutableList。接口名称一般也使用名词或名词短语（如：List），有时也可以使用形容词或形容词短语（如：Readable）。还没有特定的规则或行之有效的约定来命名注解类型。
测试类的命名，应该以它所测试的类的名字为开头，并在最后加上Test结尾。例如：HashTest、HashIntegrationTest。
5.2.3 方法名
方法名都以lowerCamelCase风格编写。
方法命名一般使用动词或者动词短语，例如：sendMessage或stop。
在JUnit 的测试方法中，可以使用下划线，用来区分逻辑组件的名字，经常使用如下的结构：test
testPop_emptyStack。并不存在唯一正确的方式来命名测试方法。
5.2.4 常量名
常量命名，全部使用大写字符，词与词之间用下划线隔开。
（CONSTANCE_CASE）。
常量的定义：每个常量都是一个静态final字段，但不是所有静态final字段都是常量。在决定一个字段是否是一个常量时，考虑它是否真的感觉像是一个常量。例如，如果任何一个该实例的观测状态是可变的，则它几乎肯定不会是一个常量。只是永远不打算改变对象一般是不够的，它要真的一直不变才能将它示为常量。
下面是常量和非常量的例子：
1.// Constants
2.static final int NUMBER =5;
3.static final ImmutableList
Ann");
4.static final Joiner COMMA_JOINER =Joiner.on(',');// because Joine
r is immutable
5.static final SomeMutableType[] EMPTY_ARRAY ={};
6.enum SomeEnum{ ENUM_CONSTANT }
7.
8.// Not constants
9.static String nonFinal ="non-final";
10.f inal String nonStatic ="non-static";
11.s tatic final Set
12.s tatic final ImmutableSet
bleSet.of(mutable);
13.s tatic final Logger logger =Logger.getLogger(MyClass.getName());
14.s tatic final String[] nonEmptyArray ={"these","can","change"};
常量一般使用名词或者名词短语命名。
5.2.5 非常量的字段名
非常量字段名以lowerCamelCase风格编写。
一般使用名词或名词短语，例如：computedValues或index。
5.2.6 参数名
参数名以lowerCamelCase风格编写。
参数应该避免用单个字符命名。
5.2.7 局部变量名
局部变量名以lowerCamelCase风格编写，比起其它类型的名称，局部变量名可以有更为宽松的缩写。
但即使如此，也应该尽量避免采用单个字母进行命名的情况，除了在循环体内使用的临时变量。
即使局部变量是final、不可改变的，它也不能被认为是常量，也不应该采用常量的命名方式去命名。
5.2.8 类型名
类型名有两种命名方式：
1. 单独一个大写字母，有时后面再跟一个数字。（例如，E、T、X、T2）。
2. 像一般的类命名一样（见5.2.2节），再在最后接一个大写字母T。（例如，
RequestT、FooBarT）。
5.3 驼峰式命名法（CamelCase）
分大驼峰式命名法(UpperCamelCase)和小驼峰式命名法(lowerCamelCase)。有时一些短语改写成驼峰形式的时候可以有多种写法。例如一些缩写词汇，或者一些组合词：IPv6 或者iOS 等。
为了统一写法，给出如下几乎可以确定为一种的写法：
1. 将字符全部转换为ASCII 字符，并且移除任何单引号。例如，"Müller's algorithm" 被
转换为"Muellers algorithm" 。
2. 将上一步转换的结果切分成单词。从空格处或其它标点符号处分割开。
3.
o注意：一些已经是驼峰式的词语，也应该在这个时候被拆分。（例如AdWords 被拆分为ad words）。但是例如iOS之类的词语，它其实不是一个驼峰式的词语，
而是人们惯例使用的一个词语，因此不用做拆分。
4. 经过上面两步后，先将所有的字母转换为小写，再把每个词语的第一个字母或除第一
个单词之外的单词的第一个字母转换为大写。
5. 最后，将所有词语连在一起，形成一个标示符。
注意：词语原来的大小写规则，应该被完全忽略。以下是一些例子：
* 号表示可以接受，但是不建议使用。
注意：有些词语在英文中，可以用- 连接使用，也可以不使用- 直接使用。例如“nonempty”和“non-empty”都是可以的。因此，方法名字为checkNonempty或者checkNonEmpty都是可以的。
六、编程实践
6.1 @override能用则用
只要是符合语法的，就把@override用上。
6.2 异常捕获不应该被忽略
一般情况下，catch住的异常不应该被忽略，而是都需要做适当的处理。例如将错误日志打印出来，或者如果认为这种异常不会发生，则应该作为断言异常重新抛出。
如果这个catch住的异常确实不需要任何处理，也应该通过注释做出说明。例如：
1.try{
2.int i =Integer.parseInt(response);
3.return handleNumericResponse(i);
4.}catch(NumberFormatException ok){
5.// it's not numberic; that's fine, just continue
6.}
7.return HandleTextResponse(response);
例外：在测试类里，有时会针对方法是否会抛出指定的异常，这样的异常是可以被忽略的。但是这个异常通常需要命名为：expected。例如：
1.try{
2. emptyStack.pop();
3. fail();
4.}catch(NoSuchElementException expected){
5.}
6.3 静态成员的访问：应该通过类，而不是对象
当一个静态成员被访问时，应该通过类名去访问，而不应该使用这个类的具体实例对象。例如：
1.Foo aFoo =...;
2.Foo.aStaticMethod();// good
3.aFoo.aStaticMethod();// bad
4.somethingThatYieldsAFoo().aStaticMethod();// very bad
6.4 不使用Finalizers方法
重载Object.finalize方法是非常非常罕见的。
提示：不应该使用这以方法。如果你认为你必须使用，请先仔细阅读并理解《Effective Java》第七条“Avoid Finalizers”。然后不要使用它。
七、Javadoc
7.1 格式规范
7.1.1 通用格式
最基本的Javadoc的通用格式如下例：
1./**
2. * Multiple lines of Javadoc text are written here,
3. * wrapped normally...
4. */
5.public int method(String p1){...}
或者为单行格式：
1./** An especially short bit of Javadoc. */
通用格式在任何时候使用都是可以的。当Javadoc 块只有一行时，可以使用单行格式来替代通用格式。
7.1.2 段落
空白行：是指Javadoc中，上下两个段落之间只有上下对齐的* 字符的行。每个段落的第一行在第一个字符之前，有一个
标签，并且之后不要有任何空格。
7.1.3 Javadoc标记
所有标准的Javadoc标记，应该按照如下的顺序添加：@param、@return、
@throws、@deprecated。并且如果这四种Javadoc标记出现，描述都不能为空。
当@从句无法在一行写完时，应该断行。延续行在第一行的@字符的位置，缩进至少4个字符单位。
7.2 摘要片段
每个类或者成员的Javadoc，都是由一个摘要片段开始的。这个片段非常重要。因为它是类或者方法在使用时唯一能看到的文本说明。
主要摘要只是一个片段，应该是一个名词短语或者动词短语，而不应该是一个完整的句子。不应该以类似于：A {@code Foo} is a...或This method returns...这样的开头，但是它应该像一个完整的句子一样使用标点符号。
提示：一种常见的错误是把单行形式的Javadoc写成：/** @return the customer ID */，这是不对的。应该改为：/** Returns the customer ID.
*/。
7.3 何处应该使用Javadoc
至少Javadoc 应该应用于所有的public类、public和protect的字段和方法。以下是一些例外：
7.3.1 例外：方法本身已经足够说明的情况
? 软件销售代理合同范本软件代码编写规范 草稿 2005.2
? 软件销售代理合同范本 1 命名规则 https://www.doczj.com/doc/1a4822868.html,命名规则 一致的命名模式是托管类库中可预知性与可发现性最重要的元素之一。对这些命名指南广泛的使用和理解将消除许多最常见的用户问题。本主题提供.NET Framework 类型的命名指南。对于每个类型，还应该注意关于大写样式、区分大小写和措词的一些通用规则。 1.1.1大写样式 描述用于在类库中命名标识符的Pascal 大小写、Camel 大小写和全部大写样式。 使用下面的三种大写标识符约定。 Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如： B ack C olor Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如： b ack C olor 大写 标识符中的所有字母都大写。仅对于由两个或者更少字母组成的标识符使用该约定。例如： System.IO System.Web.UI 可能还必须大写标识符以维持与现有非托管符号方案的兼容性，在该方案中所有大写字母经常用于枚举和常数值。一般情况下，在使用它们的程序集之外这些字符应当是不可见的。 下表汇总了大写规则，并提供了不同类型的标识符的示例。 标识符大小写示例 类Pascal AppDomain 枚举类型Pascal ErrorLevel 枚举值Pascal FatalError 事件Pascal ValueChange 异常类Pascal WebException 注意总是以Exception后缀结尾。 只读的静态字段Pascal RedValue 接口Pascal IDisposable 注意总是以I 前缀开始。 方法Pascal ToString 命名空间Pascal System.Drawing 参数Camel typeName 属性Pascal BackColor
使用说明书模板 根据所需改写即可 远程抄表能源管理系统 使用说明书 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支持软件
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了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:
产品说明书及其编写 高中通用技术技术与设计1 一、教学设计思路 本节课通过学生自主讨论探究、从而发现问题，建构新的知识体系，能够运用新的知识技能解决实际生活中的问题，坚实把握“做中学”和“学中做”的思想，不断地逐步提高学生对通用技术的理解，培养学生自主分析问题的能力，提高学生获取并理解技术知识理论的能力，提高学生应用技术具体分析、解决问题的能力。 1、教材分析 本节课是《普通高中课程标准实验教科书通用技术必修1 技术与设计1》第八单元《技术产品的使用和保养》中第一节《产品说明书及其编写》。作为本单元的入门篇目，要求理解并掌握产品说明书的定义和作用，并准确掌握产品说明书的编写方法，理解产品说明书的一般结构、表述形式、写作要求。本节课是后续课程《技术产品的使用、维护和保养》的基础，如何将产品说明书的编写与实践生活相联系，让技术思想深入学生脑海，是本节课需要攻克的一个难题。 2、学情分析 学生通过学习前面的技术课程，已经具有了一定的技术素养，这就为学习本节课奠定了一些知识基础。学生具有一定的生活和学习基础，产品说明书在他们的生活中处处可见，但对于产品说明书的认识只浮于表面，不够清晰具体，更不理解产品说明书的编写需要注意什么问题。 教材中，开题案例为“说明书表述错误引发卡式炉爆炸”，许多学生没有使用过燃气罐，缺乏亲身实践经历。若只按照教材直接讲授，难以激发学生的积极性，不能调动学生学习兴趣。本节教学应从学生能够理解的身边实例出发，让学生自己分析理解，让产品说明书深入学生的脑海。因此，本节课以自行车车轮的组装为例展开教学，激发学生学习兴趣的同时，巧妙引入产品说明书的课题。 二、教学目标 1、知识与技能：了解产品说明书的定义、作用，了解产品说明书的编写方法，结合简单的案例，能够从技术的角度出发，分别从结构、形式、要求三个方面理解产品说明书的编写。 2、过程与方法：通过观察实物、动手探究等课堂活动，结合典型案例分析，感受所学知识与实际生活的密切关系，能够通过课程内容达到编写简单产品说明书的目的。 3、情感、态度与价值观：通过课堂活动，能够激发学生的学习热情，培养动脑思考问题的良好习惯和小组合作能力的提升。 三、教学重点、难点 教学重点：理解产品说明书的定义与作用，了解说明书的结构、形式及写作要求。 教学难点：结合课程教学内容，编写简单的产品说明书。 四、教学方式、方法 1、案例分析 结合教师、学生提供的案例和课本案例进行分析，通过案例分析，达到知识传授的目
产品使用说明书编写规定 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) SAP开发规范 (3) 1说明 (3) 1.1内容说明 (3) 1.2规范目的 (3) 1.3使用说明 (3) 1.4使用对象 (3) 2一般规则 (3) 3代码管理 (4) 3.1程序标题 (4) 3.2子程序、模块标题 (5) 3.3编辑器设置 (5) 3.4代码格式 (7) 3.4.1使用规范化打印机 (7) 3.4.2查询SQL语句的写法 (7) 3.5变更记录管理 (7) 3.6代码注释 (8) 3.7子程序与函数模块 (9) 3.8其它注意事项 (9) 4数据库查询 (9) 4.1不要在L OOP循环中使用S ELECT语句 (9) 4.2取数的时候不能使用S ELECT......E NDSELECT语句循环操作 (9) 4.3尽量多使用内表 (9) 4.4S ELECT
5.2内表使用 (12) 5.2.1修改内表中的字段值 (12) 5.2.2把一个内表附加到另一个内表后面 (12) 5.2.3删除内表中重复行 (13) 5.2.4根据条件删除内表中的行 (13) 5.2.5内表是否为空的判断 (13) 5.2.6读取内表行 (13) 5.2.7通过LOOP AT it_tab ASSIGNING
代码编写安全规范 一、本总则提供编码的总体要求与遵循原则。 二、本总则制订是为了规范程序的编码风格，使项目开发过程中所有开发人员的编码有一个良好的、规范的、统一的编码风格，确保在开发成员或开发团队之间的工作可以顺利交接，同时不必花费大力气便能理解已编写的代码，以便继续维护和改进以前的工作。 三、本总则对所有技术开发部编码人有效。 四、本总则对所有开发语言有效，凡任何开发规范与本总则相冲突，以本总则为准。 五、本总则提供各种语言的编码规范，编码人员开发（编码）前应选取相应的语言编码规范进行编码。具体的“开发语言编码规范”请参见附件。 六、若总则附件中无所规范的开发语言规范，请先制订出（一般由项目经理制订）该语言的编码规范后再进行编码。 七、编码命名准则： 1、使用可以准确说明变量/字段/类的完整的英文描述符。例如，采用类似firstName，grandTotal 或CorporateCustomer 这样的名字。禁止使用一些象x1，y1 或fn 这样的名字很简短，输入起来容易，辨别含义困难的命名，使得代码难以理解、维护和改进。 2、采用领域的术语命名。如果用户称他们的“客户”(clients) 为“顾客”(customers)，那么就采用术语Customer 来命名这个类，而不用Client。保证命名使用行业或领域里已经存在着很完美的术语，避免生造词汇。
3、采用大小写混合，提高名字的可读性。一般应该采用小写字母，但类名、接口名以及任何非初始单词的第一个字母要大写，一些特殊场合以具体规范为准。 4、尽量少用缩写，但如果一定要使用，必须使用一个统一遵守的缩写，并且在使用时保持一致。例如，如果要对单词“number”采用缩写，那么可从nbr，no 或者num 中选取一个，采用其中一个（具体是哪个倒无所谓），并且只使用这一种形式。 5、避免使用长名字（最好不超过20 个字母）。避免类似如PhysicalOrVirtualProductOrService 之类的超长命名。 6、避免使用相似或者仅在大小写上有区别的名字。例如，不应同时使用变量名persistentObject 和persistentObjects，以及anSqlDatabase 和anSQLDatabase。 7、避免使用下划线作为名字的首末字母。以下划线为首末字母的名字通常为系统保留，除预处理定义之外，一般不用作用户命名。 八、编码注释准则： 1、必须明确注释的重要性。如果你的程序不值得注释，那么它也不值得运行。 2、注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。如果不能被他人所理解，则代码的注释是失败的注释，等同于无注释。 3、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。
产品说明书的写法 作者:未知来自:百度贴吧点击: 12566 时间:2007-5-29 （一）产品说明书概述 产品说明书，是对商品的性能、用途、使用和保养方法以及注意事项等作书面介绍的文书。产品说明书，又叫商品说明书。产品说明书的作用：助和指导消费者正确地认识商品、使用和保养商品，兼具宣传商品的作用。根据内容和用途的不同：可分为民用产品说明书、专业产品说明书、技术说明书等。根据表达形式的不同：可分为条款式说明书、文字图表说明书等。根据传播方式的不同，可分为：包装式：即直接写在产品的外包装上。内装式：将产品说明书专门印制，甚至装订成册，装在包装箱（盒）内。 （二）产品说明书的特点 ⒈说明性。说明、介绍产品，是主要功能和目的。 ⒉实事求是性。必须客观、准确反映产品。 ⒊指导性。还包含指导消费者使用和维修产品的知识。 ⒋形式多样性。表达形式可以文字式，也可以图文兼备。 （三）产品说明书的结构和写法 ⒈标题。一般是由产品名称加上“说明书”三字构成，如《VCD说明书》。有些说明书侧重介绍使用方法，称为使用说明书，如《吹风机使用说明》。 ⒉正文。通常详细介绍产品的有关知识：产地、原料、功能、特点、原理、规格、使用方法、注意事项、维修保养等知识。不同说明书的内容侧重点也有所不同。一般的产品说明书分为⑴家用电器类。⑵日用生活品类。⑶食品药物类。⑷大型机器设备类。⑸设计说明书。 ⒊附文。厂名、地址、电话、电挂、电传、联系人和生产日期等。出口产品在外包装上写明生产日期、中外文对照。
（四）注意事项： 突出产品特点。要注意广告和说明书的区别。如“喝孔府家酒，做天下文章”可做广告语，写入产品说明书不合适。语言要求准确、通俗、简明。尽可能图文并重。 【案例】 香雪牌抗病毒口服液使用说明书 (纯中药新药) 本品系以板兰根、藿香、连翘、芦根、生地、郁金等中药为原料，用科学方法精心研制而成。是实施新药审批法以来通过的，第一个用于治疗病毒性疾患的纯中药新药。 本品经中山医科大学附属第一医院、第一军医大学南方医院和广州市第二人民医院等单位严格的临床证，证明对治疗上呼吸道炎、支气管炎、流行性出血性结膜炎(红眼病)、腮腺炎等病毒性疾患有显著疗效。总有效率达91．27％。其中，对流行性出血性结膜炎(红眼病)和经病毒分离阳性的上呼吸道炎疗效均为100％，并有明显缩短病程的作用。 本品疗效确切，服用安全、方便，尤其适用于儿童患者，是治疗病毒性疾病的理想药物。 [性状]本品为棕红色液体，味辛，微苦。 [功能与主治]抗病毒药。功效清热祛湿，凉血解毒，用于治疗风热感冒、瘟病发热及上呼吸道感染、流感、腮腺炎等病毒感染疾患。 [用法与用量]口服，一次10ml，一日2～3次，宜饭后服用，小儿酌减。 [注意事项]临床症状较重，病程较长或合并有细菌感染的患者应加服其他治疗药物。 [规格]每支10ml。
工业产品使用说明书的编写方法 一、编写工业产品使用说明书的基本要求 编写工业产品使用说明书应符合下列四个方面基本要求： 1．应明确具体规定产品的用途和使用方法 要根据产品的使用功能和特点，具体而明确地写明产品的用途和适用范围，同时写明主要结构、性能参数、型式和规格以及正确贮运、安装、使用（操作）、维修、保护等方法。 产品使用说明书可按产品型号编写，也可按产品系列编写。 2．涉及到安全、卫生和环境保护等方面要求必须写明 当产品具有危险和有害因素时，必须在产品使用说明书中写明保护产品和操作者的安全卫生措施，对易燃、易爆、有毒、有腐蚀性和有放射性的危险产品，更应在使用说明书上规定防范措施、注意事项以及发生意外时的紧急处理办法等内容。 对影响环境的产品，使用说明书上还应规定必要的保护环境方面的内容。此外，对一些耗能较大产品应说明节能措施。 3．复杂产品和成套设备应编写系统的使用说明书
对一些复杂产品和成套设备，可按其功能单元、整机分别编写使用说明书，再组合成一套系统的使用说明书。 4．简单产品可不写使用说明书 对一些冶金、矿产、建材等原材料类产品以及用于组装配套的一些元器件、零部件等简单产品，如其产品标准、产品手册、质量证明书等有关技术文件能满足用户需要时，可由这些技术文件代管产品使用说明书，不必另行编写产品使用说明书。 二、产品使用说明书的内容构成 一般工业产品使用说明书应包括下列内容： 1．产品概述 产品概述部分主要写明产品的用途，适用范围（必要时还应写明不适用范围），产品规格型号的含义，使用环境条件或工作条件等方面内容。 2．结构特征与工作原理 该部分叙述产品结构特点及其工作原理，包括主要部件或功能单元的结构，作用及其工作原理，辅助装置的功能结构及工作原理和各单元之间的机电联系，故障告警系统等。
程序编写规范及约定 (仅供内部使用) 文档作者：_______________ 日期：___/___/___ 开发/测试经理：_______________ 日期：___/___/___ 项目经理：_______________ 日期：___/___/___ 请在这里输入公司名称 版权所有不得复制
目录 程序编写规范及约定 (3) 1编写目的 (3) 2代码编写风格 (3) 2.1单元风格 (3) 2.2语句风格 (3) 3命名规则 (3) 3.1命名约定 (3) 3.1.1标志符 (3) 3.1.2类class (3) 3.1.3枚举类型enum (4) 3.1.4委托delegate (4) 3.1.5常量const (4) 3.1.6接口interface (4) 3.1.7方法function (4) 3.1.8命名空间namespace (4) 3.1.9参数 (4) 3.1.10局部变量 (5) 3.1.11数据成员 (5) 3.1.12自定义异常类 (5) 3.1.13命名缩写 (5) 3.1.14数据库命名 (5) 3.2代码编写命名规范 (6) 3.3界面常用控件命名约定 (6) 3.4文件命名规范 (7) 3.4.1文档文件命名 (7) 3.4.2配置文件命名 (7) 3.4.3程序文件命名 (7)
程序编写规范及约定 1编写目的 为了使编写代码具有可读性、可理解性、可维护性，对程序编写人员代码实行统一风格，使得程序代码能够以名称反映含义、以形式反映结构。此文档可供程序代码编写人员及代码维护人员使用。 2代码编写风格 2.1单元风格 2.2语句风格 3命名规则 3.1命名约定 Pascal和Camel命名约定： 编程的命名方式主要有Pascal和Camel两种（Pascal：每个单词的首字母大写，例如ProductType；Camel：首个单词的首字母小写，其余单词的首字母大写，例如productType） 3.1.1标志符 规则：Pascal、Camel 实例与描述：例子说明 3.1.2类class 规则：Pascal 实例与描述：Application
软件开发代码规范（C#版） 拟制:日期：2007-2-13审核:日期： 审核:日期： 批准:日期： 版权所有 ********有限公司
修订纪录
目录 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用
小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。 1、第一章命名规范 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移
、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return ; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
产品使用说明书编写规定 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 为什么需要开发规范 编码规范对于程序员而言尤为重要，有以下几个原因： * 一个软件的生命周期中，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 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在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() */ 意:与溢出中断写初值不同}
工业产品使用说明书标准 工业产品使用说明书总则 1 基本要求 1.1 使用说明书是交付产品的组成部分. .使用说明书应明确给出产品用途和适用范围,并根据产品的特点和需要给出主要结构,性能参数,型式与规格和正确吊运. 安装.使用.操作.维修.保养 和贮存等方法,以及保护操作者和产品的安全措施. .对影响环境和能源的产品,使用说明书还应规定必要的保护环境和节约能源方面的内容 .对易烧.易爆,有毒.有腐蚀性,有放射性等产品.还应包括防护措施. 注意事 项和发生意外时的紧急处理办法等内容. 1.2 当产品结构,.性能等有改动而影响使用时,使用说明书的有关内容必须
作相应修改. 1.3 使用说明书可按产品型编制,也可按产品系列, 成套性编制.按系列.成套性编制时,其内容和参数不同之部分必须明显区分. .复杂产品和成套设备可按功能单元.整机分别编制使用说明书, 再按产品型号,用途组合成系统的使用说明书. 1.4 冶金.矿产,建材等原材料类产品及用于主机厂配套的元器件等产品,如质量证明书. 产品标准.产品手册等技术文件能满足用户需要时,则可用其代替使用说明书. 2 一般规定 2.1 使用说明书的印制 .使用说明书应能长期使用,保证在产品预期寿命期内的可用性.(批量定型产
品的使用说明书.一般应采用铅印).使用说明书的文字,符号,图示.表格,照 片等应清晰.整齐.双面印制者,不得因透背等原因而影响阅视. 2.2 使用说明书的文本 .使用说明书的开本幅面,一般应附合下列规定. a.铅印本:64开(92mm*12mm) 32开(130mm*184mm) 16开(188mm*260mm) 必要时采用其他幅面尺寸,但应符合GB788的规定. b.晒印本:A4号图纸(210mm*297mm)表格. 图形等允许向横向加长.确属必要时方可向纵向加长.数量多的大幅面附图. 附表可分装 .使用说明书根据内容多少可为单页.折页和多页.多页应装订成册. .供给国内用户的工业产品必须有汉文使用说明书, 出品工业产品一般应编
软件开发代码规（C#版） 拟制: 日期：2007-2-13 审核: 日期： 审核: 日期： 批准: 日期： 所有 ********
修订纪录
目录 1、第一章命名规 (4) 1.1、第一节总则 (4) 1.2、第二节变量命名规 (4) 1.2.1、CodeBehind部命名规 (4) 1.2.2、控件命名规 (5) 1.3、第三节常量命名规 (5) 1.4、第四节命名空间、类、方法命名规 (5) 1.5、第五节接口命名规 (6) 1.6、第六节命名规小结 (6) 2、第二章代码注释规 (6) 2.1、第一节模块级注释规（命名空间、类等） (6) 2.2、第二节方法级注释规 (7) 2.2.1 、属性注释 (7) 2.2.2 、方法注释 (7) 2.3、第三节代码间注释规 (8) 3、第三章编写规 (8) 3.1、第一节格式规 (8) 3.2、第二节编程规 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (9) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (10) 3.2.6 、interface使用注意事项 (11) 3.2.7 、类使用注意事项 (11) 3.2.8 、流程控制语句注意事项 (12) 3.2.8 、其他应注意事项 (13) 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。
1、第一章命名规 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移 1.2、第二节变量命名规 1.2.1、CodeBehind部命名规 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return https://www.doczj.com/doc/1a4822868.html,erName; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
FORTRAN 90 程序编程规范 Fortran 90 编程规范，使程序代码高度组织化，更加易读、易懂、易于维护，程序更加高效。使编出的程序更易懂、易于维护。 1 语言选择 数值预报创新系统软件开发应避免使用Fortran77 的某些过时特征以Fortran 90不一致的特征。选择Fortran 90 作为开发语言，并采用Fortran 90 的新功能，如动态内存的分配(dynamic memory allocation)、递归（recursion ）, 模块(modules)、POINTER 、长变量名、自由格式等。 Fortran 77其中某些只是一些冗余的功能，这些功能已经过时，另外，还有一些在Fortran90 中被证明是不好的用法，建议不要使用。 2 Fortran 90 的新特性 2.1.1 建议使用的Fortran 90 新特性 建议使用Fortran 90 提供的模块（module ），并用Use ONLY 指定module 中哪些变量或派生类型定义可用于调用程序。 尽量使用数组下标三元组，这样可优化并减少所需的代码行数。为提高可读性，要在括号内表明数组的维数，例如： 1dArrayA(:) = 1dArrayB(:) + 1dArrayC(:) 2dArray(: , :) = scalar * Another2dArray(: , :) 当访问数组的子集时，例如在有限差分等式中，可以通过使用下标三元组实现。例如：2dArray(: , 2:len2) = scalar *（ & Another2dArray(:, 1:len2 -1) & - Another2dArray(:, 2:len2) & ) 对程序单元（program units ）命名，并使用End program ，End subroutine ，End interface ，End module 等结构再次指定“program unit ”的名称。 在逻辑表达式中使用>、 >=、 ==、 <、 <=、 /=，它们分别代 替.gt.、.ge.、.eq.、.lt.、.le.、.ne. 。新的表示方法更接近标准的数学符号 在变量定义中始终使用“：：”；始终用“DIMENSION ”定义数组形状；始终用（len=）的语法格式声明字符变量的长度。
骨科常见无源植入类产品说明书编写规范 （征求意见稿） 本编写规范旨在规范常见骨科无源植入类产品说明书的格式和内容，指导说明书的编写。同时规范注册申报和技术审评工作，为医疗器械注册管理部门的技术审评人员提供说明书审核的参考内容，从而降低资料发补率，统一审评尺度，提高审评效率。最终力求上市说明书格式清晰、用语准确，确保使用者和操作者能够从产品说明书中获得清晰、准确的信息，确保产品临床使用的安全有效。 本编写规范的编写参考了国内已上市的、具有代表性的国产及进口骨科无源植入类产品的说明书，但说明书内容应首先符合国家食品药品监督管理总局《医疗器械说明书、标签和包装标识管理规定》的有关要求。 本编写规范中的说明书参考格式系对常见骨科无源植入类产品说明书中主流和典型的说明书特征的归纳总结，涵盖了关节（附件1—附件8）、脊柱（附件9—附件23）、创伤（附件24—附件52）、骨填充物（附件52+）等相关产品的说明书。参考格式均包括但不限于如下标题项：医疗器械注册证书编号；产品技术要求编号；医疗器械生产许可证编号；产品名称；产品性能、结构及组成；型号、规格；适用范围；禁忌症；并发症；注意事项；警示；安装使用说明及图示；储存条件；有效期限；制造商名称；制造商注册地址
；生产地址；售后服务机构；代理人的名称、地址及联系方式；标签所用的图形、符号、缩写等内容的解释；其他。申请人/制造商应依据所申报产品的具体特性和支持性资料确定参考格式中具体内容（除标题项名称“【】”中的内容）是否适用，并对适用的内容进行充实和细化(包括增加标题项)，对不适用的内容进行修改和删除，确保说明书内容与申报资料相一致。说明书至少应包括标题项所规定的内容项目，制定说明书前请仔细阅读各标题项后“注”的内容。各类产品的具体参考格式详见附件。 本编写规范中通用的标题项及其注解如下： 【医疗器械注册证书编号】 注：取得医疗器械产品注册证后填写。 【产品技术要求编号】 注：取得医疗器械产品技术要求编号后填写。 【医疗器械生产许可证编号】 注：境内产品适用。 【产品名称】 注：产品名称应能体现产品技术结构特征和功能属性，属于体现产品性能结构及组成的描述性词语应在说明书的内容中予以体现。产品名称的命名应与已发布的国家标准、行业标准、医疗器械产品分类目录以及其他发布的规范中的产品名称保持一致。若产品能明确其所属注册单元，则产品名称