目录
一、介绍 (1)
1.1 术语说明 (1)
1.2 文档说明 (1)
二、源码文件基础 (2)
2.1 文件名 (2)
2.2 文件编码：UTF-8 (2)
2.3 特殊字符 (2)
2.3.1 空格字符 (2)
2.3.2 特殊转义字符串 (2)
2.3.3 非ASCII字符 (2)
三、源码文件结构 (4)
3.1 lincense 或者copyright的声明信息。 (4)
3.2 包声明 (4)
3.3 import语句 (4)
3.3.1 不使用通配符import (4)
3.3.2 没有行长度限制 (4)
3.3.3 顺序和空行 (4)
3.4 类声明 (5)
3.4.1 只声明唯一一个顶级class (5)
3.4.2 类成员顺序 (5)
四、格式 (6)
4.1 花括号 (6)
4.1.1 花括号在需要的地方使用 (6)
4.1.2 非空语句块采用K&R风格 (6)
4.1.3 空语句块：使代码更简洁 (7)
4.2 语句块的缩进：2空格 (7)
4.3 一行最多只有一句代码 (7)
4.4 行长度限制：80或100 (7)
4.5 长行断行 (7)
4.5.1 在何处断行 (8)
4.5.2 断行的缩进：至少4个字符 (8)
4.6 空白空间 (8)
4.6.1 垂直空白 (8)
4.6.2 水平空白 (9)
4.6.3 水平对齐：不做强制要求 (9)
4.7 分组括号：建议使用 (10)
4.8 特殊结构 (10)
4.8.1 枚举类型 (10)
4.8.2 变量声明 (10)
4.8.3 数组 (11)
4.8.4 switch语句 (11)
4.8.5 Annotations (12)
4.8.6 注释 (13)
4.8.7 修饰符 (13)
五、命名 (14)
5.1 适用于所有命名标识符的通用规范 (14)
5.2 不同类型的标示符规范 (14)
5.2.1 包名 (14)
5.2.2 类名 (14)
5.2.3 方法名 (14)
5.2.4 常量名 (15)
5.2.5 非常量的成员变量名 (15)
5.2.6 参数名 (15)
5.2.7 局部变量名 (16)
5.2.8 类型名 (16)
5.3 Camel case的定义 (16)
六、编程实践 (18)
6.1 @override 都应该使用 (18)
6.2 异常捕获不应该被忽略 (18)
6.3 静态成员的访问：应该通过类，而不是对象 (18)
6.4 不使用Finalizers 方法 (19)
七、Javadoc (20)
7.1 格式规范 (20)
7.1.1 通用格式 (20)
7.1.2 段落 (20)
7.1.3 @从句 (20)
7.2 摘要片段 (21)
7.3 何处应该使用Javadoc (21)
7.3.1 例外：方法本身已经足够说明的情况 (21)
7.3.2 例外：重载方法 (21)
7.3.3 例外：可选的javadoc (21)
一、介绍
本文档为Google Java编程规范的完整定义。依照此规范编写的Java源码文件可以被称为Google Style。
和其他编程规范指南一样，规范不仅包括了代码的结构美学，也包括了其他一些业界约定俗成的公约和普遍采用的标准。本文档中的规范基本都是业界已经达成共识的标准，我们尽量避免去定义那些还存在争议的地方。
1.1 术语说明
本文档除非特殊说明，否则：
a、class（类）统指普通的class类型、enum枚举类型、interface类型和annotation类型。
b、comment（注释）总是指implementation comments（实现注释，/* */）。我们不使用“文档注释”这样的说法，而会直接说javadoc。
其他术语说明，将在文档中需要说明的地方单独说明。
1.2 文档说明
本文档中的代码并不一定符合所有规范。即使这些代码遵循Google Style，但这不是唯一的代码规范。例子中可选的格式风格也不应该作为强制执行的规范。
二、源码文件基础
2.1 文件名
源码文件名由它所包含的顶级class的类名（大小写敏感），加上.java后缀组成。（除了package-info.java文件）。
2.2 文件编码：UTF-8
源码文件使用UTF-8编码。
2.3 特殊字符
2.3.1 空格字符
除了换行符外，ASCII水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着：
a、其他空白字符将被转义。
b、Tab字符不被用作缩进控制。
2.3.2 特殊转义字符串
任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \', \\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode码（例如\u000a）表示。
2.3.3 非ASCII字符
对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者使用对应的Unicode 码（例如\u221e）转义，都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
注意：在使用unicode码转义，或者甚至是有时直接使用unicode字符的时候，添加一点说明注释将对别人读懂代码很有帮助。
例子：
Example Discussion
String unitAbbrev ="μs";Best: perfectly clear even without a comment.
String unitAbbrev ="\u03bcs";// "μs"Allowed, but there's no reason to do this.
String unitAbbrev ="\u03bcs";// Greek letter mu, "s"Allowed, but awkward and prone to mistakes.
String unitAbbrev ="\u03bcs";Poor: the reader has no idea what this is.
return'\ufeff'+ content;// byte order mark Good: use escapes for non-printable characters,
and comment if necessary.
注意：不要因为担心一些程序无法正常处理费ASCII字符而不使用它，从而导致代码易读性变差。如果出现这样的问题，应该由出现问题的程序去解决。
三、源码文件结构
源码文件按照先后顺序，由以下几部分组成：
a、License或者copyright声明信息。（如果需要声明）
b、包声明语句。
c、import语句。
d、class类声明（每个源码文件只能有唯一一个顶级class）。
每个部分之间应该只有一行空行作为间隔。
3.1 lincense 或者copyright的声明信息。
如果需要声明lincense或copyright信息，应该在文件开始时声明。
3.2 包声明
包声明的行，没有行长度的限制。单行长度限制（4.4部分有详细说明，80或100）不适用于包声明。
3.3 import语句
3.3.1 不使用通配符import
不应该使用通配符import，不管是否是静态导入。
3.3.2 没有行长度限制
import语句的行，没有行长度的限制。单行长度限制（4.4部分有详细说明，80或100）不适用于import语句所在行。
3.3.3 顺序和空行
import语句应该被分为几个组，每个组之间由单行的空行隔开。分组的顺序如下：
a、所有的static import为归为一组。
b、com.google 包的import归为一组。
c、使用的第三方包的引用。每个顶级第三方包归为一组。第三方包之间按ASCII码排序。例如：android, com, junit, org, sun
d、java包归为一组。
e、javax包归为一组。
同一组内的import语句之间不应用空行隔开。同一组中的import语句按ASCII码排序。
3.4 类声明
3.4.1 只声明唯一一个顶级class
每个源码文件中只能有一个顶级class。package-info.java文件除外。
3.4.2 类成员顺序
类成员的顺序对代码的易读性有很大影响，但是没有一个统一正确的标准。不同的类可能有不同的排序方式。
重要的是，每个class都要按照一定的逻辑规律排序。当被问及时，能够解释清楚为什么这样排序。例如，新增加的成员方法，不是简单地放在class代码最后面，按日期排序不是按逻辑排序。
3.4.2.1 重载方法：不应该分开
当一个类有多个构造函数，或者多个同名成员方法时，这些函数应该写在一起，不应该被其他成员分开。
四、格式
术语说明：块状结构（block-like construct）指类、成员函数和构造函数的实现部分（花
括号中间部分）。注意，在后面的4.8.3.1节中讲到数组初始化，所有的数组初始化都可以被认为是一个块状结构（非强制）。
4.1 花括号
4.1.1 花括号在需要的地方使用
花括号一般用在if, else, for, do, 和while等语句。甚至当它的实现为空或者只有一句话时，也需要使用。
4.1.2 非空语句块采用K&R风格
对于非空语句块，花括号遵循K&R风格：
a、左括号前不换行。
b、左括号后换行。
c、右括号前换行。
d、如果右括号结束一个语句块或者函数体、构造函数体或者有命名的类体，则需要换行。例如，当右括号后面接else或者逗号时，不应该换行。
例子：
一些例外的情况，将在4.8.1节讲枚举类型的时候讲到。
4.1.3 空语句块：使代码更简洁
一个空的语句块，可以在左花括号之后直接接右花括号，中间不需要空格或换行。但是当一个由几个语句块联合组成的语句块时，则需要换行。（例如：if/else-if/else try/catch/finally）.
例子：
void doNothing(){}
4.2 语句块的缩进：2空格
每当一个新的语句块产生，缩进就增加两个空格。当这个语句块结束时，缩进恢复到上一层级的缩进格数。缩进要求对整个语句块中的代码和注释都适用。（例子可参考之前4.1.2节中的例子）。
4.3 一行最多只有一句代码
每句代码的结束都需要换行。
4.4 行长度限制：80或100
不同的项目可以选择采用80个字符或者100个字符作为限制。除了以下几个特殊情况外，其他代码内容都需要遵守这个长度限制。这在4.5节会有详细解释。
例外：
a、按照行长度限制，无法实现地方（例如：javadoc中超长的URL地址，或者一个超长的JSNI方法的引用）；
b、package和import语句不受长度限制。（见3.2、3.3节）；
c、注释中的命令行指令行，将被直接复制到shell中执行的。
4.5 长行断行
术语说明：当一行代码按照其他规范都合法，只是为了避免超出行长度限制而换行时，称为长行断行。
长行断行，没有一个适合所有场景的全面、确定的规范。但很多相同的情况，我们经常使用一些行之有效的断行方法。
注意：将长行封装为函数，或者使用局部变量的方法，也可以解决一些超出行长度限制的情况。并非一定要断行。
4.5.1 在何处断行
断行的主要原则是：选择在更高一级的语法逻辑的地方断行。其他一些原则如下：
a、当一个非赋值运算的语句断行时，在运算符号之前断行。（这与Google的C++规范和JavaScrip规范等其他规范不同）。
b、当一个赋值运算语句断行时，一般在赋值符号之后断行。但是也可以在之前断行。
c、在调用函数或者构造函数需要断行时，与函数名相连的左括号要在一行。也就是在左括号之后断行。
d、逗号断行时，要和逗号隔开的前面的语句断行。也就是在逗号之后断行。
4.5.2 断行的缩进：至少4个字符
当断行之后，在第一行之后的行，我们叫做延续行。每一个延续行在第一行的基础上至少缩进四个字符。
当原行之后有多个延续行的情况，缩进可以大于4个字符。如果多个延续行之间由同样的语法元素断行，它们可以采用相同的缩进。
4.6.3节介绍水平对齐中，解决了使用多个空格与之前行缩进对齐的问题。
4.6 空白空间
4.6.1 垂直空白
单行空行在以下情况使用：
a、类成员间需要空行隔开：例如成员变量、构造函数、成员函数、内部类、静态初始化语句块（static initializers）、实例初始化语句块（instance initializers）。
例外：成员变量之间的空白行不是必需的。一般多个成员变量中间的空行，是为了对成员变量做逻辑上的分组。
b、在函数内部，根据代码逻辑分组的需要，设置空白行作为间隔。
c、类的第一个成员之前，或者最后一个成员结束之后，用空行间隔。（可选）
d、本文档中其他部分介绍的需要空行的情况。（例如3.3节中的import语句）
单空行时使用多行空行是允许的，但是不要求也不鼓励。
4.6.2 水平空白
除了语法、其他规则、词语分隔、注释和javadoc外，水平的ASCII空格只在以下情况出现：
a、所有保留的关键字与紧接它之后的位于同一行的左括号之间需要用空格隔开。（例如if、for、catch）
b、所有保留的关键字与在它之前的右花括号之间需要空格隔开。（例如else、catch）
c、在左花括号之前都需要空格隔开。只有两种例外：
@SomeAnnotation({a, b})
String[][] x = {{"foo"}};
d、所有的二元运算符和三元运算符的两边，都需要空格隔开。
e、逗号、冒号、分号和右括号之后，需要空格隔开。
f、// 双斜线开始一行注释时。双斜线两边都应该用空格隔开。并且可使用多个空格，但是不做强制要求。
g、变量声明时，变量类型和变量名之间需要用空格隔开。
h、初始化一个数组时，花括号之间可以用空格隔开，也可以不使用。（例如：
new int[]{5,6}和new int[]{5,6}都可以）
注意：这一原则不影响一行开始或者结束时的空格。只针对行内部字符之间的隔开。4.6.3 水平对齐：不做强制要求
术语说明：水平对齐，是指通过添加多个空格，使本行的某一符号与上一行的某一符号上下对齐。
这种对齐是被允许的，但是不会做强制要求。
以下是没有水平对齐和水平对齐的例子;
private int x;// this is fine
private Color color; // this too
private int x;// permitted, but future edits
private Color color;// may leave it unaligned
注意：水平对齐能够增加代码的可读性，但是增加了未来维护代码的难度。考虑到维护时只需要改变一行代码，之前的对齐可以不需要改动。为了对齐，你更有可能改了一行代码，同时需要更改附近的好几行代码，而这几行代码的改动，可能又会引起一些为了保持对齐的代码改动。那原本这行改动，我们称之为“爆炸半径”。这种改动，在最坏的情况下可能会导致大量的无意义的工作，即使在最好的情况下，也会影响版本历史信息，减慢代码review的速度，引起更多merge代码冲突的情况。
4.7 分组括号：建议使用
非必须的分组括号只有在编写代码者和代码审核者都认为大家不会因为没有它而导致代码理解错误的时候，或者它不会使代码更易理解的时候才能省略。没有理由认为所有阅读代码的人都能记住所有java运算符的优先级。
4.8 特殊结构
4.8.1 枚举类型
每个逗号后接一个枚举变量，不要求换行。
枚举类型，如果没有函数和javadoc，处理格式是可以按照数组初始化来处理。
例子：
private enum Suit{ CLUBS, HEARTS, SPADES, DIAMONDS }
枚举类型也是一种类（Class），因此Class类的其他格式要求，也适用于枚举类型。4.8.2 变量声明
4.8.2.1 每次声明一个变量
不要采用一个声明，声明多个变量。例如int a, b;
4.8.2.2 当需要时才声明，尽快完成初始化
局部变量不应该习惯性地放在语句块的开始处声明，而应该尽量离它第一次使用的地方最近的地方声明，以减小它们的使用范围。
局部变量应该在声明的时候就进行初始化。如果不能在声明时初始化，也应该尽快完成初始化。
4.8.3 数组
4.8.3.1 数组初始化：可以类似块代码处理
所有数组的初始化，都可以采用和块代码相同的格式处理。例如以下格式都是允许的：
4.8.3.2 不能像C风格一样声明数组
方括号应该是变量类型的一部分，因此不应该和变量名放在一起。例如：应该是String[] args，而不是String args[]。
4.8.4 switch语句
术语说明：switch语句是指在switch花括号中，包含了一组或多组语句块。每组语句块都由一个或多个switch标签（例如case FOO：或者default：）打头。
4.8.4.1 缩进
和其他语句块一样，switch花括号之后缩进两个字符。
每个switch标签之后，后面紧接的非标签的新行，按照花括号相同的处理方式缩进两个字符。在标签结束后，恢复到之前的缩进，类似花括号结束。
4.8.4.2 继续向下执行的注释
在switch语句中，每个标签对应的代码执行完后，都应该通过语句结束（例如：break、continue、return 或抛出异常），否则应该通过注释说明，代码需要继续向下执行下一个标签的代码。注释说明文字只要能说明代码需要继续往下执行都可以（通常是//fall through）。这个注释在最后一个标签之后不需要注释。例如：
4.8.4.3 default标签需要显式声明
每个switch语句中，都需要显式声明default标签。即使没有任何代码也需要显示声明。
4.8.5 Annotations
Annotations应用到类、函数或者构造函数时，应紧接javadoc之后。每一行只有一个Annotations。
Annotations所在行不受行长度限制，也不需要增加缩进。例如：
@Override
@Nullable
public String getNameIfPresent(){...}
例外情况：
如果Annotations只有一个，并且不带参数。则它可以和类或方法名放在同一行。例如：
@Override public int hashCode(){...}
Annotations应用到成员变量时，也是紧接javadoc之后。不同的是，多个annotations可以放在同一行。例如：
@Partial@Mock DataLoader loader;
对于参数或者局部变量使用Annotations的情况，没有特定的规范。
4.8.6 注释
4.8.6.1 语句块的注释风格
注释的缩进与它所注释的代码缩进相同。可以采用/* */ 进行注释，也可以用// 进行注释。当使用/**/ 进行多行注释时，每一行都应该以* 开始，并且* 应该上下对齐。
例如：
多行注释时，如果你希望集成开发环境能自动对齐注释，你应该使用/**/，//一般不会自动对齐。
4.8.7 修饰符
多个类和成员变量的修饰符，按Java Lauguage Specification中介绍的先后顺序排序。具体是：
public protected private abstract static final transient volatile synchronized native strictfp
五、命名
5.1 适用于所有命名标识符的通用规范
标示符只应该使用ASCII字母、数字和下划线，字母大小写敏感。因此所有的标示符，都应该能匹配正则表达式\w+ 。
Google Style中，标示符不需要使用特殊的前缀或后缀，例如：name_, mName, s_name和kName。
5.2 不同类型的标示符规范
5.2.1 包名
包名全部用小写字母，通过 . 将各级连在一起。不应该使用下划线。
5.2.2 类名
类型的命名，采用以大写字母开头的大小写字符间隔的方式（UpperCamelCase）。class命名一般使用名词或名词短语。interface的命名有时也可以使用形容词或形容词短语。annotation没有明确固定的规范。
测试类的命名，应该以它所测试的类的名字为开头，并在最后加上Test结尾。例如：HashTest 、HashIntegrationTest。
5.2.3 方法名
方法命名，采用以小写字母开头的大小写字符间隔的方式（lowerCamelCase）。
方法命名一般使用动词或者动词短语。
在JUnit的测试方法中，可以使用下划线，用来区分测试逻辑的名字，经常使用如下的结构：test
测试方法也可以用其他方式进行命名。
5.2.4 常量名
常量命名，全部使用大写字符，词与词之间用下划线隔开。（CONSTANCE_CASE）。
常量是一个静态成员变量，但不是所有的静态成员变量都是常量。在选择使用常量命名规则给变量命名时，你需要明确这个变量是否是常量。例如，如果这个变量的状态可以发生改变，那么这个变量几乎可以肯定不是常量。只是计划不会发生改变的变量不足以成为一个常量。下面是常量和非常量的例子：
常量一般使用名词或者名词短语命名。
5.2.5 非常量的成员变量名
非常量的成员变量命名（包括静态变量和非静态变量），采用lowerCamelCase命名。
一般使用名词或名词短语。
5.2.6 参数名
参数命名采用lowerCamelCase命名。
应该避免使用一个字符作为参数的命名方式。
5.2.7 局部变量名
局部变量采用lowerCamelCase命名。它相对于其他类型的命名，可以采用更简短宽松的方式。
但即使如此，也应该尽量避免采用单个字母进行命名的情况，除了在循环体内使用的临时变量。
即使局部变量是final、不可改变的，它也不能被认为是常量，也不应该采用常量的命名方式去命名。
5.2.8 类型名
类型名有两种命名方式：
a、单独一个大写字母，有时后面再跟一个数字。（例如，E、T、X、T2）。
b、像一般的class命名一样（见5.2.2节），再在最后接一个大写字母。（例如，RequestT、FooBarT）。
5.3 Camel case的定义
有时一些短语被写成Camel case的时候可以有多种写法。例如一些缩写词汇，或者一些组合词：IPv6 或者iOS 等。
为了统一写法，Google style给出了一种几乎可以确定为一种的写法。
a、将字符全部转换为ASCII字符，并且去掉' 等符号。例如，"Müller's algorithm" 被转换为"Muellers algorithm" 。
b、将上一步转换的结果拆分成一个一个的词语。从空格处和从其他剩下的标点符号处划分。
注意：一些已经是Camel case的词语，也应该在这个时候被拆分。（例如AdWords 被拆分为ad words）。但是例如iOS之类的词语，它其实不是一个Camel case的词语，而是人们惯例使用的一个词语，因此不用做拆分。
c、经过上面两部后，先将所有的字母转换为小写，再把每个词语的第一个字母转换为大写。
d、最后，将所有词语连在一起，形成一个标示符。
注意：词语原来的大小写规则，应该被完全忽略。以下是一些例子：
* 号表示可以接受，但是不建议使用。
注意，有些词语在英文中，可以用- 连接使用，也可以不使用- 直接使用。例如“nonempty”和“non-empty”都是可以的。因此，方法名字为checkNonempty 或者checkNonEmpty 都是可以的。
六、编程实践
6.1 @override 都应该使用
@override annotations只要是符合语法的，都应该使用。
6.2 异常捕获不应该被忽略
一般情况下，catch住的异常不应该被忽略，而是都需要做适当的处理。例如将错误日志打印出来，或者如果认为这种异常不会发生，则应该作为断言异常重新抛出。
如果这个catch住的异常确实不需要任何处理，也应该通过注释做出说明。例如：
例外：在测试类里，有时会针对方法是否会抛出指定的异常，这样的异常是可以被忽略的。但是这个异常通常需要命名为：expected。例如：
6.3 静态成员的访问：应该通过类，而不是对象
当一个静态成员被访问时，应该通过class名去访问，而不应该使用这个class的具体实例对象。例如：
1.程序块采用缩进风格,空格为4个. 说明: 对于开发工具自动生成的代码可以不一致 2.分界符(如大括号{和})应各自占一行并且在同一列,同时与引用它们的 语句左对齐,在方法的开始,类和接口的定义,以及if,for,do,while,switch,case语句都要采用上述缩进 说明: for(…) { … 说明: if(filename != null && new File(logPath+filename).length() < ()) { 3.…作符) 说明: 采用这种松散方式编写代码目的是让程序更加清晰,由于空格所产生的清晰性是相对的,所以在已经很清晰的语句中没有必要留空格,如果语句已足够清晰,则括号内侧(即左括号后面和右括号前面)不需要加空格,多重括号间不必加空格,因为java中括号已经是很清晰的标志了. 在长句中,如果需要加的空格非常多,那么应该保持整体清晰,而在局部
中不加空格,给操作符留空格时不要连续留两个以上空格 4.类属性和方法不要交叉放置,不同存取范围的属性和方法也不要交叉放 置 说明: 类定义:{ 类公有属性定义; 类保护属性定义; 类私有属性定义; 类公有方法定义; 类保护方法定义; 类私有方法定义; } 5.源程序的有效注释量必须在30%以上 6.包的注释写入一个名为的html格式的说明文件放入当前路径 7.包的注释内容:本包作用,详细描述本包内容,产品模块名称及版本,公 司版本 说明:
一句话描述 详细描述产品模块
公司版本信息 8.文件注释:写入文件头部,包名之前 9.文件注释内容:版本说明,描述信息,修改历史,生成日期 说明: /* *文件名 *版权 *描述 *修改人 *修改时间 *修改内容 *跟踪单号 *修改单号 */ 10.类和接口注释:放在package注释之后,class或interface之前 11.类和接口注释内容:类的注释要一句话功能描述,功能详细描述 说明:
项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）JS代码、HTML代码及数据库设计均应遵守这个规范。同时，也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解，方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法
姓名： ____________ 工号：_______________ 部门：____________ 成绩： 一. 判断题(共15题，每题2分，直接在括号内打“/或“X”) 1、任何时候都不要使接口可以序列化。x 2、相对独立的程序块之间、变量说明之后必须加空行。V 3、当程序需要释放对象的时候，应该手工调用fin alize 方法以释放对象。x 4、公司的规范要求注释率是20%以上，并且必须有助于对程序的阅读理解。x 5、为了程序更加简洁，我们应该尽量使用下面的方式来赋值： a = b = 1 。x 6、每个类都需要定义构建器。x 7、类名、方法名、属性名的命名，都应该使用意义完整的英文描述。V 8、main() 方法的定义是public static void main(String args[]) 。x 9、常量名应该使用全大写，英文单词之间用下划线或者-分隔开。并且，常量应该使用final static 修饰。x 10、公有方法参数名可以和属性名相同，但局部变量不能和属性名相同。V 11、一两行代码就能完成的功能没有必要编写方法实现。x 12、对于模块间接口方法的参数的合法性检查，调用者和被调用者都应该对参数进行合法性检查。 x 13、运行期异常使用RuntimeException的子类来表示，必须在方法声明上加throws子句。x非运行 期异常是从Exception继承而来的，不用在可能抛出异常的方法声明上加throws子句。x 14、使用Objectstream 的方法后，调用release()，释放对象。X 15、减小单个方法的复杂度，使用的if, while, for, switch 语句要在10个以内。V 二、单项选择题(共23题，每题2分) (c ) 1、排版时，代码缩进应该采用的方式是： (A)Tab缩进 (B)2个空格缩进
变更履历
目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小
Java编程规范本文引用阿里Java开发手册。GitHub阅读地址： 目录 编程规约 - 命名规约 - 常量定义 - 格式规范 - OOP规约 - 集合处理 - 并发处理 - 控制语句 - 注释规约 - 其他 - 异常处理 - 建表规约 - 索引规约 - SQL规约
- ORM规约 编程规约 命名规约 1、【强制】所有编程相关命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束 反例： _name / __name / $Object / name_ / name$ / Object$1 2、【强制】所有编程相关的命名严禁使用拼音与英语混合的方式，更不允许直接使用中的方式。 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即纯拼音的命名方式也要避免采用。 反例： DaZhePromotion [打折] / getPingfenByName() [评分] / int 变量 = 3; 正例： ali / alibaba / taobao / cainiao / aliyun / youku / hangzhou 等国际通用的名称，可视为英文。12345 3、【强制】类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名） DO / DTO / VO / DAO 等。 正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例： macroPolo / UserDo / XMLService / TCPUDPDeal
/ TAPromotion123 4、【强制】方法名、参数名、成员变量、局部变量都统一只用 lowerCamelCase 风格，必须遵从驼峰形式。 正例： localValue / getHttpMessage() / inputUserId1 5、【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。 正例： MAX_STOCK_COUNT 反例： MAX_COUNT123 6、【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。 7、【强制】中括号是数组类型的一部分，数组定义如下：String[] args ; 反例：请勿使用 String args[] 的方式来定义1 8、【强制】 POJO 类中的任何布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。 反例：定义为基本数据类型 boolean isSuccess；的属性，它的方法也是 isSuccess()， RPC框架在反向解析的时候，“以为”对应的属性名称是 success，导致属性获取不到，进而抛出异常。1 9、【强制】包名统一使用小写，点分隔符之间有且仅有一
1 Java 编程规范 1.1 排版 1.1.1 规则 规则1程序块要采用缩进风格编写，缩进的空格数为4个，不允许使用TAB缩进。(1.42+) 说明：缩进使程序更易阅读，使用空格缩进可以适应不同操作系统与不同开发工具。 规则2分界符（如大括号…{?和…}?）应各独占一行，同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序 或者static、,synchronized等语句块中都要采用如上的缩进方式。(1.42+) 示例: if (a>b) { doStart(); } 规则3较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐， 语句可读。(1.42+) 示例： if (logger.isDebugEnabled()) { logger.debug("Session destroyed,call-id" + event.getSession().getCallId()); } 规则4不允许把多个短语句写在一行中，即一行只写一条语句(1.42+) 说明：阅读代码更加清晰 示例：如下例子不符合规范。 Object o = new Object(); Object b = null; 规则5if, for, do, while, case, switch, default 等语句自占一行，且if, for, do, while,switch等语句的执行语句无论多少都要加括号{},case 的执行语句中如果定义变量必须加括号{}。 (1.42+) 说明：阅读代码更加清晰，减少错误产生 示例： if (a>b) { doStart(); }
1.软件开发手册 1.1.围 本标准规定了基于公司信息系统构建平台进行业务应用系统开发的编程格式规，主要包括命名规、代码注释、性能、以及常用语句的书写要求和约束等。统一规的格式有利于项目的交付和后续维护。 1.2.引言 1.1.1.简介 所有的程序开发手册都包含了各种规则。一些习惯自由程序的人（例如 Java 程序员）可能对这些规则很不适应，但是在多个开发人员共同协作的情况下，这些规则是必需的。这不仅仅是为了开发效率，而且也为了测试和后期维护。 良好的编码习惯有助于标准化程序的结构和编码风格，使源代码对于自己和别人都易读和易懂。在开发周期中越早使用恰当的编码规定，将会最大程度的提高项目的生产率。良好的编码习惯除了代码格式，详细的注释外，还应该包括使用有助于提高程序效率的编码方式。 规的开发有助于提高源码的可读性，可维护性，对于提高项目的整体效率更是不可缺少的（尤其是团队开发）。 1.1. 2.目的 本文是一套面向Java programmer 和Java developer进行开发所应遵循的开发规。按照此规来开发Java程序可带来以下益处： ●代码的编写保持一致性， ●提高代码的可读性和可维护性， ●在团队开发一个项目的情况下，程序员之间可代码共享， ●易于代码的回顾。 1.3.源程序 1.3.1.源程序命名 Java源程序的名字应该是这种形式：ClassOrInterfaceName.java。ClassOrInterfaceName 应该是在Java源程序中定义的 class或者interface的名字（关于classes和interface的命
名规请参考3.2）。源程序的文件名后缀通常为.java。 1.3. 2.供发布的文件 如果文件编译后，需要用打包的形式发布，那么这个包的名字应该是有代表性的（例如应该是这个模块或者这个文件所在单元的名字）。通常包的扩展名有 *.jar(推荐使用)或者 *.zip、*.ear、*.war等。 1.3.3.源文件的组织 一个Java源文件应该包含如下的元素，并按照以下顺序书写： 1)版本信息和声明 2)包的声明 3)引用声明 4)类或者接口的声明 以上元素之间以至少一个空行来分隔。 1.3.3.1.版本信息和声明 每一个源程序应该以一个包含版本信息和声明的块为开始。 例如： /** * application name： sample1 * application describing： this class handels the request of the client * copyright： Copyright ? 2002 金质工程所有 * company： neusoft * time： 2002.02.25 * * author Brunce * version ver 3.1 */
Java语言编码规范 Prepared by 拟制Date 日期 yyyy-mm-dd Reviewed by 评审人Date 日期 yyyy-mm-dd Approved by 批准Date 日期 yyyy-mm-dd
Revision Record 修订记录
Table of Contents 目录 1. 范围 (4) 2. 规范性引用文件 (4) 3. 术语和定义 (4) 4. 排版规范 (5) 4.1. 规则 (5) 4.2. 建议 (7) 5. 注释规范 (9) 5.1. 规则 (9) 5.2. 建议 (15) 6. 命名规范 (17) 6.1. 规则 (17) 6.2. 建议 (18) 7. 编码规范 (20) 7.1. 规则 (20) 7.2. 建议 (24) 8. JTEST规范 (26) 8.1. 规则 (26) 8.2. 建议 (27)
1.范围 本规范规定了使用Java语言编程时排版、注释、命名、编码和JTEST的规则和建议。 本规范适用于使用Java语言编程的产品和项目。 2.规范性引用文件 下列文件中的条款通过本规范的引用而成为本规范的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本规范，然而，鼓励根据本规范达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本规范。 3.术语和定义 规则：编程时强制必须遵守的原则。 建议：编程时必须加以考虑的原则。 格式：对此规范格式的说明。 说明：对此规范或建议进行必要的解释。 示例：对此规范或建议从正、反两个方面给出例子。
项目开发规范文档修订历史记录
1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册
3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。
一、单选题 1. 如下关于集合类的描述错误的是B A. 含有集合意义的属性命名，尽量包含其复数的意义 B. 集合中的数据不需要释放，垃圾回收器会自动回收 C. 集合必须指定模板类型 D. 使用集合类时要设置初始化容量 2. 关于线程以下说法错误的有B A. 新起一个线程，都要使用Thread.setName(“…”)设置线程名 B. 在JDK1.5或更新的版本中，若字符串拼接发生在单线程环境，使用StringBuffer C. 对多线程访问的变量、方法，必须加锁保护，避免出现多线程并发访问引起的问题 D. 线程使用时，要在代码框架中使用线程池，避免创建不可复用的线程；禁止在循环中创建新线程，否则会引起JVM资源耗尽 3. 下面哪个是推荐使用的对称密码算法B A. DES B. AES C. SHA D. RSA
4. 以下说法正确的有C A. 程序中的一些状态多直接用数字表示，如函数执行成功return 1 B. 对于表示函数执行错误，多用约定的错误码来标识 C. 用有意义的静态变量或者枚举来代替数字型的程序状态，如函数执行成功return SUCCESS D. 程序中的魔鬼数字并不可怕，需要所有开发人员努力理解这些数字的含义 5. 下列错误使用异常的做法是D A. 在程序中使用异常处理还是使用错误返回码处理，根据是否有利于程序结构来确定，并且异常和错误码不应该混合使用，推荐使用异常 B. 一个方法不应抛出太多类型的异常。throws/exception子句标明的异常最好不要超过三个 C. 异常捕获尽量不要直接catch (Exception ex)，应该把异常细分处理 D. 程序内抛出的异常本身就可说明异常的类型、抛出条件，可不填写详细的描述信息。捕获异常后用exception.toString()取到详细信息后保存 6. 关于命名规范，以下说法错误的有D A. 属性名使用意义完整的英文描述，第一个单词的字母使用小写，剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同 B. 方法名使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法 C. 方法中，存取属性的方法采用setter 和getter方法，动作方法采用动词和动宾结构
多选 1.如何处理单元测试产生的数据，下列哪些说法是正确的？ABC A .测试数据入库时加特殊前缀标识。 B .测试数据使用独立的测试库。 C .自动回滚单元测试产生的脏数据。 D .无须区别，统一在业务代码中进行判断和识别。 多选 2.关于并发处理，下列哪些说法符合《阿里巴巴Java开发手册》：ABC A .线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。 B .同步处理时，能锁部分代码区块的情况下不要锁整个方法；高并发时，同步调用应该考虑到性能损耗。 C .创建线程或线程池时，推荐给线程指定一个有意义的名称，方便出错时回溯。 D .推荐使用Executors.newFixedThreadPool(int x)生成指定大小的线程池。(线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式) 多选 3.下列哪些说法符合《阿里巴巴Java开发手册》：ACD A .对于“明确停止使用的代码和配置”，如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去，避免造成过多垃圾。 B .永久弃用的代码段注释掉即可，即不用加任何注释。 C .对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。 D .不要在视图模板中加入任何复杂的逻辑。 多选 4.关于分页查询，下列哪些说法符合《阿里巴巴Java开发手册》：ABC A .分页查询，当统计的count为0时，应该直接返回，不要再执行分页查询语句。 B .iBATIS自带的queryForList(String statementName,int start,int size)分页接口有性能隐患，不允许使用。 C .定义明确的sql查询语句，通过传入参数start和size来实现分页逻辑。 D .可使用存储过程写分页逻辑，提高效率。
项目编码规范 1 命名规范 1）.包名采用域后缀倒置的加上自定义的包名，采用小写字母。 在部门内部应该规划好包名的范围，防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。 格式： com.huawei.产品名.模块名称 com.huawei.部门名称. 项目名称 示例： Relay模块包名 com.huawei.msg.relay 通用日志模块包名 com.huawei.msg.log 2）. 类名和接口使用类意义完整的英文描述，每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。 示例： OrderInformation, CustomerList, LogManager, LogConfig 3）. 方法名使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。 示例： private void calculateRate(); public void addNewOrder(); 4）. 方法中，存取属性的方法采用setter 和 getter方法，动作方法采用动词和动宾结构。格式： get + 非布尔属性名() is + 布尔属性名() set + 属性名() 动词() 动词 + 宾语() 示例： public String getType(); public boolean isFinished(); public void setVisible(boolean); public void show();
public void addKeyListener(Listener); 5）.属性名使用意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。 示例： private customerName; private orderNumber; private smpSession; 6). 常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用 final static 修饰。 示例： public final static int MAX_VALUE = 1000; public final static String DEFAULT_START_DATE = "2001-12-08"; 7). 属性名可以和公有方法参数相同，不能和局部变量相同，引用非静态成员变量时使用 this 引用，引用静态成员变量时使用类名引用。 示例： public class Person { private String name; private static List properties; public void setName (String name) { https://www.doczj.com/doc/e87973255.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例： getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释（必须加）
JAVA编程规范--试题 姓名：工号：部门：成绩： 一. 判断题（共15题，每题2分，直接在括号内打“√”或“×”） 1、任何时候都不要使接口可以序列化。x 2、相对独立的程序块之间、变量说明之后必须加空行。√ 3、当程序需要释放对象的时候，应该手工调用finalize方法以释放对象。x 4、公司的规范要求注释率是20％以上，并且必须有助于对程序的阅读理解。x 5、为了程序更加简洁，我们应该尽量使用下面的方式来赋值：a = b = 1 。x 6、每个类都需要定义构建器。x 7、类名、方法名、属性名的命名，都应该使用意义完整的英文描述。√ 8、main() 方法的定义是public static void main(String args[])。x 9、常量名应该使用全大写，英文单词之间用下划线或者-分隔开。并且，常量应该使用 final static修饰。x 10、公有方法参数名可以和属性名相同，但局部变量不能和属性名相同。√ 11、一两行代码就能完成的功能没有必要编写方法实现。x 12、对于模块间接口方法的参数的合法性检查，调用者和被调用者都应该对参数进行合 法性检查。x 13、运行期异常使用RuntimeException的子类来表示，必须在方法声明上加throws子句。 x非运行期异常是从Exception继承而来的，不用在可能抛出异常的方法声明上加throws 子句。x 14、使用ObjectStream 的方法后，调用release() ，释放对象。X 15、减小单个方法的复杂度，使用的 if, while, for, switch 语句要在10个以内。√ 二、单项选择题(共23题，每题2分) （ c ）1、排版时，代码缩进应该采用的方式是： （A）Tab缩进 （B）2个空格缩进 （C）4个空格缩进 （D）8个空格缩进
项目团队开发规范
修订历史记录
目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12)
3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18)
1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书，描述了项目开发过程中的使用的工具，框架，代码编写规范及注意问题，作为项目团队建设，开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类： ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。
Java编程规范 目录 Java编程规范 (1) 1编码规则 (1) 2命名规范 (7) 2.1类名、变量名（非final）、方法名 (7) 2.2驼峰式命名 (7) 2.3不能使用没有任何含义的英文字母进行命名 (7) 2.4不能使用拼音进行命名，统一使用准确的英文进行命名 (8) 2.5包名 (8) 2.6接口与类的命名 (8) 2.7抽象类命名 (8) 2.8实现类命名 (8) 2.9工具类命名 (8) 2.10变量命名 (8) 2.115、方法命名 (9) 2.12系统的命名约定 (9) 1编码规则 1、数据库操作、IO操作等需要使用结束close()的对象必须在try -catch-finally 的finally中close()，如果有多个IO对象需要close()，需要分别对每个对象的close()方法进行try-catch,防止一个IO对象关闭失败其他IO对象都未关闭。 手动控制事务提交也要进行关闭，对大对象进行关闭操作 示例： try { // ... ... } catch(IOException ioe) { //... ... } finally { try { out.close();
} catch(IOException ioe) { //... ... } try { in.close(); } catch(IOException ioe) { //... ... } } 2、系统非正常运行产生的异常捕获后，如果不对该异常进行处理，则应该记录日志。 说明：此规则指通常的系统非正常运行产生的异常，不包括一些基于异常的设计。若有特殊原因必须用注释加以说明。 logger.error(ioe，“[类.方法]描述”,参数); 示例： try { //.... ... } catch(IOException ioe) { logger.error(ioe); } 3、自己抛出的异常必须要填写详细的描述信息。 说明：便于问题定位。 示例： throw new IOException("Writing data error! Data: "+ data.toString()); 4(删除)、在程序中使用异常处理还是使用错误返回码处理，根据是否有利于程序结构来确定，并且异常和错误码不应该混合使用，推荐使用异常。 说明： 一个系统或者模块应该统一规划异常类型和返回码的含义。 但是不能用异常来做一般流程处理的方式，不要过多地使用异常，异常的处理效率比条件分支低，而且异常的跳转流程难以预测。
管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法， 团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。
武汉中软卓越科技有限公司Java语言编码规范
Table of Contents 目录 1. 范围 (3) 2. 术语和定义 (3) 3. 排版规范 (4) 3.1. 规则 (4) 3.2. 建议 (6) 4. 注释规范 (7) 4.1. 规则 (7) 4.2. 建议 (12) 5. 命名规范 (14) 5.1. 规则 (14) 5.2. 建议 (15) 6. 编码规范 (17) 6.1. 规则 (17) 6.2. 建议 (20) 7. JTEST规范 (22) 7.1. 规则 (22) 7.2. 建议 (23)
1.范围 本规范规定了使用Java语言编程时排版、注释、命名、编码和JTest的规则和建议。 本规范适用于使用Java语言编程的案例、产品和项目。 2.术语和定义 规则：编程时强制必须遵守的原则。 建议：编程时必须加以考虑的原则。 格式：对此规范格式的说明。 说明：对此规范或建议进行必要的解释。 示例：对此规范或建议从正、反两个方面给出例子。
3.排版规范 3.1.规则 3.1.1.*程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 3.1.2.*语句块分隔符左括号‘{’应与语句块引用代码在同一行，右括号‘}’应另起一行并 与语句块引用代码左对齐。在函数体的开始、类和接口的定义、以及if、for、do、 while、switch、case语句中的程序都要采用如上的缩进方式。 示例：如下例子不符合规范。 for (...) { ... // program code } if (...) { ... // program code } void example_fun( void ) { ... // program code } 应如下书写： for (...){ ... // program code } if (...){ ... // program code } void example_fun( void ){ ... // program code } 3.1.3.*较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作 符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： if (filename != null && new File(logPath + filename).length() < LogConfig.getFileSize()){ ... // program code } public static LogIterator read(String logType, Date startTime, Date endTime, int logLevel, String userName, int bufferNum) 3.1.4.*不允许把多个短语句写在一行中，即一行只写一条语句
精心整理 管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、 2、 3、跟踪设计/开发/测试/回归/ 4、/跨部门协 调等几个方面。 5、 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 2 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。
跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态) 定情况执行补丁升级。 6、收尾阶段 产品交付，项目总结会。 常见问题 1、开发时间的估算 算，通常单个模块开发时间取决于以下因素： 1 2(包括对框架和应用的熟悉程度)。 3 开发者没有相关的代码可以参考，自己也没有经验， 1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。 2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下： A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开 发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。 B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
JAVA代码规范 本Java代码规范以SUN的标准Java代码规范为基础，为适应我们公司的实际需要，可能会做一些修改。本文档中没有说明的地方，请参看SUN Java标准代码规范。如果两边有冲突，以SUN Java标准为准。 1. 标识符命名规范 1.1 概述 标识符的命名力求做到统一、达意和简洁。 1.1.1 统一 统一是指，对于同一个概念，在程序中用同一种表示方法，比如对于供应商，既可以用supplier，也可以用provider，但是我们只能选定一个使用，至少在一个Java项目中保持统一。统一是作为重要的，如果对同一概念有不同的表示方法，会使代码混乱难以理解。即使不能取得好的名称，但是只要统一，阅读起来也不会太困难，因为阅读者只要理解一次。 1.1.2 达意 达意是指，标识符能准确的表达出它所代表的意义，比如：newSupplier, OrderPaymentGatewayService等；而supplier1, service2，idtts等则不是好的命名方式。准确有两成含义，一是正确，而是丰富。如果给一个代表供应商的变量起名是order，显然没有正确表达。同样的，supplier1, 远没有targetSupplier意义丰富。 1.1.3 简洁 简洁是指，在统一和达意的前提下，用尽量少的标识符。如果不能达意，宁愿不要简洁。比如：theOrderNameOfTheTargetSupplierWhichIsTransfered 太长，transferedTargetSupplierOrderName则较好，但是transTgtSplOrdNm就不好了。省略元音的缩写方式不要使用，我们的英语往往还没有好到看得懂奇怪的缩写。 1.1.4 骆驼法则 Java中，除了包名，静态常量等特殊情况，大部分情况下标识符使用骆驼法则，即单词之间不使用特殊符号分割，而是通过首字母大写来分割。比如: supplierName, addNewContract，而不是supplier_name, add_new_contract。