Java编码规范

2 年 ago

科, 颖

3 minutes

首先

请注意以下事项，并运用它们来提高Java代码的可读性和可信赖性。

「インデントは….」などと言ったありがちなものは入っていないので、他のサイトを参照されたい.

规则

首先只提供规则。解释在后面参考。

变量和常量

変数名で業務固有の名称をつける必要がない場合は、変数の型を連想する名称とする

类别定义

必要に応じてクラス内にローカルなクラスを作成する

实现和继承

インスタンスクラスはequals,hashCode,Comparable,cloneを実装する.

方法

Overloadはなるべくしない⇒ソースが分かりやすくなる

逻辑

例外処理ではfinalyは必ずつける、原則catchはしない

共通的课程

企業内であれば、長期的展望をもって、整備していくべき

讲解

变量和常量

布尔类型(Boolean)不应该作为参数使用，应该使用枚举(enum)。

当将boolean用作方法的参数时，很难理解。
需要确认方法的规格才能理解。
如果使用enum，意义就更加清晰了。
在方法内部进行局部使用或作为方法的返回值，没有什么问题。

在中文中重新定義和使用boolean(Boolean)。

isActive的布尔值为true。

下述的比上述的更容易理解。

boolean ACTIVE = true;
boolean IN_ACTIVE = false;
boolean status = IN_ACTIVE;

布尔类型 ACTIVE = true;
布尔类型 IN_ACTIVE = false;
布尔类型 status = IN_ACTIVE;

如果将其作为方法参数，也能理解其意义，但即使传递不同含义的boolean，也不会编译错误。实际上，使用enum会更好。

boolean（布尔）不使用否定形式的名称

这个理由很难理解，当在否定条件下更难理解，再加上其他条件一起更难理解。

boolean notFound = true;
if (! notFound) {
// 見つかった時の処理.
}

布尔值未找到 = true;
如果 (!布尔值未找到) {
// 被找到时的处理.
}

尽量避免使用String⇒改为使用字符串包装类

理由是因为以String的形式不容易理解。
名字是String，住址是String，公司名是String，部门名也是String都无法了解。
无论进行怪异的赋值还是传入错误的参数都不会导致编译错误。
其实我很想定义一个类CompanyName继承String，但是不可以，因为String是final类型。
因此我会定义一个类CompanyName，其中包含一个私有String成员变量。

然而，在任何情况下都要尝试这样做可能会相当麻烦。
需要重新定义String类的方法（只需必要的部分）。
在使用外部库时，总是需要进行转换和逆转换。

因此，将封闭在自己的系统中的内容创建为String内包类。
将需要与外部库进行传递的内容坚持使用String。

将null进行重新定义并使用 ⇒ 类名+IS_NULL

当将null赋值或传递给方法时，其含义不明确，尤其是在传递给方法时。

地址类：
// 省略处理

我的类：
public void 方法(地址 addr)：
// 省略处理

这样的话，不清楚传递了什么样的null。
MyClass myObj = new MyClass();
myObj.method(null); // ⇒ 不清楚办法

如果按照以下方式进行:
Address Address_IS_NULL = (Address)null;
myObj.method(Address_IS_NULL); // ⇒ 更容易理解

如果以以下方式进行：

注：在定义null时，最好是在类（在这个例子中是Address类）内部进行定义。
引用Address.IS_NULL。
然而，当不是自己负责时，可以采用上述的方式。

不使用int常数，而是使用enum。

如果使用 int，即使赋予了非法值也不会被检查。但是在现有系统中如果使用了 int 常量，则使用 int 常量是不可避免的。

// 使用int定义性别
final int GENDER_MALE = 1;
final int GENDER_FEMALE = 2;
int intGender = GENDER_MALE;
intGender = 100; // 不会导致编译错误

用枚举来表示可能比上述方法更好。
Gender enumGender = Gender.MALE;

为了避免相等判断的Bug，不要使用int常量等同于Integer变量。

这将被判定为假。
如果出现错误，则无法确定。

不要使用表示离散状态的字符串常量⇒使用枚举

如果没有使用int常量，那么这也和不使用它一样。无效的值将不会被检查。
但是如果在现有系统中使用了String常量，那是无可奈何的。

最后一个字符串变量不会导致编译错误。

将上述内容改为枚举类型。
性别枚举类型 enumGender = Gender.FEMALE。

如果在数据库上是以数字或文本形式，而在内存中是枚举类型，则兼容性不佳，需要进行相互转换。通过在该枚举类型中实现静态的fromInt（fromString）方法和toInt（toString）方法，就能创建一个通用类来进行转换。

如果在执行时不发生变化的事项，应该使用数组而不是列表来定义。而需要在逻辑中生成的事项，则应该使用列表而不是数组。

在决定使用数组还是列表时可能会感到困惑，但设定这样的原则会很有帮助。

不要对固定数进行硬编码。

如果只写下一个常数，那就无法理解其含义。
在进行修正时，可能会错误地修正其他部分处于相同值的地方。

// 当把status的值改为其他值时，可能会误改gender的值，这样就无法理解其意义。
int status = 1; // 无法理解其意义
int gender = 1; // 无法理解其意义

将以下内容进行重述，以使其更易理解，且无需进行更改。
状态常量STATUS_ACTIVE的值为1；
状态常量STATUS_INACTIVE的值为2；
性别常量GENDER_MALE的值为1；
性别常量GENDER_FEMALE的值为2；
status变量的值为STATUS_ACTIVE，容易理解；
gender变量的值为GENDER_MALE，容易理解。

注意，对于这个例子来说，最好改成枚举形式。

避免重复使用变量

一个变量应该只用于一个意义。

虽然我知道这一点，但在忙碌的时候还是可能出错，所以要注意。

尽量避免对变量进行重新赋值。

多次对变量进行赋值时，当使用该变量进行处理时，其值会变得难以理解。
什么情况才被视为”再赋值”是微妙的。
例如以下情况应该没有问题。
在循环中逐个处理实例时，将值赋给实例变量或相关变量。
设置初始值，在某些条件下更新该值，然后使用该变量进行处理。
不好的情况的示例。
在对变量赋值后使用该变量进行处理，然后再次将其值赋给该变量，再次使用该变量进行处理。
参考”将一系列的处理放入代码块中”。

在中文中，类型参数在前面加上$符号。

为了清晰地说明意图是通过类型参数实现的，
如果上述意图能够实现，也可以使用其他方法，但最好不要违反其他规则的范围。

如果不需要为变量起特定于业务的名称，可以将变量命名为能够联想到其类型的名称。

如果是String类型，可以使用str等等。
特别是在共享类中，这样做会更好。

类定义

实例类（暂称为数据存放类）将字段整理在开头，并将字段注释放在一行中。

为了快速了解字段列表，原因是希望在查看源代码时，可以一眼看到开头部分以便快速理解有哪些字段。因此，只需在开头部分定义字段并将字段注释写入一行而不换行。

逻辑类（暂定名称：逻辑中心类）的字段应在最后进行记录。

在逻辑类中，我们想要了解公开的方法。
作为使用类的立场，我们并不需要了解内部处理使用的字段，因此应该在最后进行描述。
公开的变量和常量应该在开头进行描述，但私有的常量最好在最后进行描述。

只在需要的时候给类加上public。

明显在自己的包外被引用的东西应该设为public。
其他的类不应该（暂时）设为public。
如果需要的话，可以在那个时候设为public，但这时候会出现“这个应该设为public吗？”的思考时机。
问题在于，其他包的责任人可能会在不知道可用的类的情况下创建类似的类。

在构造函数中，仅进行字段初始化，而不执行实质性的处理。

或许不是必须的，但应该是常识。
普通构造函数通常不会添加太多处理，如果添加了其他处理，可能会导致他人误解。

将字段初始化的方法设为final。

领域不在声明行中初始化，而是在初始化方法中进行。
这样能更清楚地知道正在初始化什么。
当需要重新初始化时很方便。
将其设置为final是为了防止重写。在构造函数中调用的方法被重写会出问题。详细省略。
注意，需要另外考虑继承类的初始化方法的名称。

在系统中统一命名字段的初始化方法（例如init等）

为了避免误解，当然要避免给其他目的的方法起与初始化方法相同的名字。

当在构造函数或方法中没有处理时，可以写上”无操作”。

构造函数
当没有处理时，明确表示这一点是正确的。
然而，如果字段的初始化已被方法化，那么应该有一些处理。
继承的类的构造函数可能没有处理。
可以看出，“在考虑是否需要处理之后，判断是不需要处理的”。

方法
可能存在没有处理的方法吗？⇒在重写方法的情况下是可能存在的。
将其标注为“没有处理”⇒在这种情况下，将其描述出来是很重要的。
可以知道是在考虑了是否需要处理之后，判断不需要处理。

创建一个Comparator的实例类。

虽然很多情况下并不需要，但总之还是原则上”进行创建”。
如果个别判断认为”在这个类中是不必要的”，也可以。

在多个逻辑类中使用的实例类也可以考虑将接口分离。

考虑将操作逻辑类通过接口传递给其他类。
不让传递的类做任何自主决策。
明确传递的类应该做些什么。
为了这个目的，创建一个接口可能是一个好选择。

不要创建只包含常量的接口⇒改为类⇒不可知是否implements

原因如上所述。如果是在类中，则写出类名称，这样可以清楚地了解是哪个常量，以及在哪里定义。

如果在静态代码块中不得不引发异常⇒记录日志和抛出运行时异常。

请注意，这是一个相当特殊的情况。
在共通类中有一个静态常量，使用静态代码块来初始化它会很方便。
因为它会在第一次使用时执行，所以不需要考虑执行时机的问题。
然而，静态代码块不能抛出异常（会导致编译错误）。
如果在静态代码块中确实存在异常，可以在内部进行捕获，然后输出日志并抛出 RuntimeException，这样就能通过编译了。

根据需要，在类内创建局部类。

那些在其他地方不会被使用的课程应该在本地定义。
将其暴露在外会让人讨厌，容易引起误解。
将变量尽可能地限制在一个小范围内同样适用。

实现和继承

创建一个名为“Dummy”的虚拟库接口（如Comparator、Iterator等），然后使用它。

原因在于，通过JavaDoc可以立即了解Comparator的列表。

// 这样做。
interface 我们的比较器 extends Comparator {}
class 我们的类 implements 我们的比较器 { …. }

在实现和继承中，将原始名称前加上前缀的名称。

以下是理由:
可以立即知道名字代表什么实现和继承
在Eclipse中会显示在旁边。

例如，可以按照以下方式来实现。
/** 员工类 */
class 员工 {}
/* 管理职位类 */
class 管理职位 extends 员工 {}

問題點
這個名稱在英文中不太合適。
當存在多個實現和繼承時，需要限定一個。
如果層次變成多個，名稱將逐漸變長。

当不希望使用基类方法时，将其设为RuntimeException。

创建派生类时，可能会出现基类方法不再需要的情况。通过覆盖这个方法并引发RuntimeException，可以防止错误的调用。

在类定义和方法中，根据需要，可以使用final关键字。

这是常识，但似乎很少有人实践。我也是这样。
所以最好将其制定为规则，以免忘记。

实例类要实现toString方法。

由于对调试等工作非常有用，所以一定要实现。
只需将所需字段toString并连接起来，就能创建通用的辅助工具。

实例类需要实现equals、hashCode、Comparable和clone。

在这些中有很多是不必要的。
将其规定为实现的规则，然后针对“这个类不需要实现”的情况进行个别判断。

## 方法

在方法的名称中不使用否定形

特别是对于返回值为布尔类型的情况。
使用与布尔变量同名的变量名可能会让人难以理解。
虽然有时并不难以理解，但仍需要个别判断来确定。

返回值为List等时，若无值，则返回null比返回空（大小为零）更为常见。

如果为空，可以将数据可取与数据不可取时的处理方式相同。这是它的优点。

然而，也可以说需要明确判断才更好。
关于选择哪一个，我们可以统一通过系统来决定。
请参阅”在原来的类中创建一个判断返回值是否正常的静态方法”。

在原始类中创建一个静态方法来判断返回值是否正常。

当返回值被返回后，接下来的处理将由调用方自行决定。
无法确定是否会按照方法的本意进行解释。

为了尽可能改善，请按以下方式进行：
类名为MyClass的类：
/** 调用方法 **/
public String method(String str) {
// 具体操作
return null; // 发生错误
}

/* 判断返回值的方法 */
public static boolean errorHappened(String value) {
return (value == null);
}

MyClass myObj = new MyClass();
String returnValue = myObj.method(“aaaa”);
if (MyClass.errorHappened(returnValue)) {
// 错误处理
}

我知道有人批评说「过火」。

把返回值为布尔类型的方法命名为适应if语句的名称。

类 MyClass {
public boolean check(String str) {
// 进行某些操作
return true;
}
public boolean checkNormalEnded(String str) {
// 进行某些操作
return true;
}
}

MyClass myObj = new MyClass();
// 这样的话，我不太明白 if 语句的意思
if (myObj.check(“aaaa”)) {
// 进行某些处理

如果我的对象检查正常结束，并且理解了这一点，
if (myObj.checkNormalEnded(“aaaa”)) {
// 进行一些处理
}

在返回值中不要使用内部对象的List, Set, Map等，如果需要的话，应返回其副本。

如果返回内部的List等，有可能会被任意修改，所以选择复制并返回一个副本。顺便提一下，ArrayList可以克隆，但是List不可以克隆。

想要返回多个值时该怎么做？⇒创建一个类

创建一个用于返回值的类。
但是如果这个类在其他地方无法使用，那将非常令人懊悔。
不过通常情况下，我们会忍受懊悔，并采取这种做法。

当想要返回多个返回值时应该怎么做？– 返回对象数组 – 创建一个用于提取值的静态方法。

// 如果你绝对不喜欢前述情况，可以按照以下方式进行操作
class Box {
public Object[] getSize() {
// 第一个元素代表高度，第二个元素代表宽度
return new Integer[]{5, 10};
}
public static Integer getHeight(Object[] values) {
return (Integer)values[0];
}
public static Integer getWidth(Object[] values) {
return (Integer)values[1];
}
}

Box box = new Box();
Object[] values = box.getSize();
int width = Box.getWidth(values);
int height = Box.getHeight(values);

箱子 box = new 箱子();
物体[] values = box.大小();
int 宽度 = 箱子.宽度(values);
int 高度 = 箱子.高度(values);

不需要的内部数据的方法应该设为静态。

不需要进行new操作，只需写出类名就能清晰理解其意思。
我认为这样做很常见，但有时会看到将其设为实例方法。

尽量避免过载，以便使代码更加易懂。

, shǐ yì .)

如果检查参数就能区分，但很麻烦，应该通过方法名称进行区分

逻辑

在编程时，注重易理解性而不是处理速度。

如果需要速度，就这样做。现在这一认识被视为理所当然。

如果你觉得逻辑很“难、复杂”，就要重新思考一次。 nǐ “, “, .)

考虑以下事项：
有没有更简单的逻辑？
思考方式是否正确？
本来需要的逻辑吗？
如果仍然需要，那就坚持去做！

进行整理的处理被分组为一个块

为了实现一个操作，有时需要编写多行代码。例如，将值赋给一些变量并调用方法等。
在这种情况下，可以将这些一系列的代码行组合成一个代码块，并将缩进减少一级。
通过将其变为代码块，可以看出这些行是一系列相关的操作。
可以给整个代码块添加注释。
由于可以在代码块内部定义变量，可以防止变量的误操作。

这是一个关于整个代码块的注释，在代码块内部写下一系列的操作：
{
int a = 0;
String str = “abc”;
// 接下来是其他操作.
}

在else语句中进行换行。

很多人会像这样编写if-else语句：
int a = 1;
if (a == 1) {
// 需要执行的操作
} else {
// 另一种操作
}

将其描述为下面这样的原因是可以在整个else部分添加注释。请参考上面的”将重复的处理放入块中”。

如果 (a == 1) {
// 需要执行的操作
}
// 如果不满足条件时的操作⇒这是else的整个注释
否则 {
// 另一种操作
}

使用三个运算符

这是理所当然的，我们经常会见到未使用的程序。行数增多，冗长，难以阅读，令人烦躁。但是不使用嵌套的三元运算符。

如果没有else时，也可以使用三元运算符来减少代码行数。例子：a = (logic expression) ? a = (algebraic expression) : a;

如果if语句的内容只包含了break、continue、return、throw这些关键字，那么可以将它们与if语句放在同一行上进行编写。

如果（条件）{ 退出循环; }

为了减少行数，尽量在屏幕上显示更多内容的原因。
其他情况下，由于逻辑会混乱在下方流动，所以被禁止。

在中文中，判断String的相等性可以使用equals方法。

有时候会偶尔看到一些以“==”进行判断的程序。如果仔细观察它们，可能会感到头晕。而且有时这些程序还能通过测试。能通过测试的原因是因为它们循环复制，并且结果相等。

将字符串的等值判断以常数作为主语。

为了防止出现null错误，需要进行适当的null检查。当确实需要进行null检查时，需要在前一行进行检查。

字符串 str = “bbbb”;
if (“aaaa”.equals((str))) { // 注意：实际上应将 “aaaa” 定义为常量
// 匹配时的处理
}

在中文中，有不需要创建布尔值对象

在中国的原生语言中进行改写，仅需给出一个选项：
Boolean只能是true、false（和null），并且由Boolean类定义，不需要进行实例化。
注意，(new Boolean(true)) == (new Boolean(true))会返回false.

布尔值 boolValue = 布尔值.真。

null需要明确类型

当将其赋值给变量时，尽管还好，但当作为参数传递时容易出错。
这会引发不安，并需要查看对方的方法以进行确认。

类MyClass{
public void method(String str){
// 执行某些操作
}
}

我通过以下方式实现：
MyClass myObj = new MyClass();
myObj.method((String)null);

实际上，最好重新定义null。请参考“重新定义null并使用⇒类名+IS_NULL”。

如果、对于、当被视作一个块，即使只有一句话也是如此。

理由是因为当试图添加句子时会出现错误。

在需要考虑顺序的循环中，不使用增强型for循环。

虽然结果是相同的，但在源代码上看不出是按顺序进行处理。

如果需要处理顺序号，不使用增强型for循环是很自然的。但是，例如在”按输入顺序处理”的情况下，即使不使用顺序号，也不使用增强型for循环。

考虑使用常量表来划分，而无需使用分支(if,switch)。

以下是使用if语句的例子
int a = 1;
String msg;
if (a == 0) {
msg = “aaaa”;
}
else if (a == 1) {
msg = “bbbb”;
}
//继续进行下去。

用以下方式进行：
String[] msgs = new String[] {“aaaa”,”bbbb”};
msg = msgs[a];

这个例子没有价值，但是在制作状态机等时，如果不这样做就会混乱。但请注意，如果原始值不是从零开始，就需要将数组设为两层。只有常量表，所以它会变得更短、更易读⇒错误会变少。

在else条件下没有处理时，注释为”无处理”。

int a = 0;
if (a == 0) {
// 写入某些处理
}
else {
// 不进行处理
}

当然地，对于所有的if语句，不一定要这样做，只有当有疑问的空间时才需要。
这可以传达出“在考虑是否需要else处理后，判断它是不必要的”的意思。

将复合条件分解并嵌套在if语句中。

在使用if语句时，有时会出现多个条件通过”and”连接而变得难以理解的情况。这种情况下，应当解析条件并将if语句进行嵌套。

即使受到”素人”的批评，也不能动摇。重要的是避免bug，并且注重使代码更易理解。

将复合条件用括号分隔并明确表示。

当多个条件通过and/or连接在一起时，如果用括号()将它们分隔开来，会更容易阅读。

尽量重复使用对象

由于创建对象的成本很高，如果重新使用，可能会出错。不用担心，最好还是创建新对象。当然，在需要考虑性能的情况下可以进行重用。

在调用静态方法时，必须使用类名而不是变量名。即使在自己的类中，也要写上类名。

调用静态方法的行为更加明确，使得源代码更易于阅读。

尽量不要使用StringBuilder（StringBuffer）。

尽管这可能会受到批评，但源代码的易读性更重要。
确实，性能会有所不同。然而，在许多情况下，绝对时间本来就很少。
除非进行非常多的循环等操作时，不建议使用StringBuilder。
值得注意的是，在我的测试中，当不使用StringBuilder（或StringBuffer）进行字符串拼接时，所需时间大约是它的10倍。

为了方便进行单元测试，将内存中的逻辑转移到方法中。

这也是情境判断的一部分，一定程度放宽外出是好的。然而，如果做得过多，方法的数量就会变多，会引起混乱。

向List、Set、Map等对象添加子对象时，应在创建子对象之后立即进行添加。

为了防止在新增后忘记添加处理程序这种情况，需要形成一个习惯，以免忘记。这将有助于防止出现难以理解的错误（有时）。

当存在上述例外时，是在设置新创建对象的值，并且在特定条件下可能不进行添加。

在异常处理中，必须始终使用finaly，通常不使用catch。

无论是catch还是不catch异常，可能都会出现，但是不catch的情况可能更多。
请记得在最后加上finally语句块。
即使不需要进行finally处理，也可以添加一个空的finally块，并写上”无处理”。

共同的课程

创建一个共同的类来处理日期和时间⇒统一日期格式、统一日期和时间处理

在系统的各个方面，我们可以看到有很多相同的处理方式来处理日期和时间。相同的格式被描述在各个地方。特别是在进行日期处理时，由于时间误差可能会引入错误，因此需要采取措施来防止这种情况发生。

创建共享类来处理反射、通信、IO等，以避免与其他逻辑混合。

就像将数据库访问作为DAO外部化一样，将这些类似的特殊处理操作统一放在共用的类中。

将方法的参数数字数组转换为包装器而不是原始类型。

在原始类型中，需要为每种类型创建方法。
在包装类中，可以统一使用Number。不过，BigDecimal也属于Number，这就很棘手了。

为了使类名和方法名更加易懂，创建一个派生类。

在共通类中，有时类名和方法名与业务内容不相符。这种情况下，可以定义派生类并使用易于理解的名称。但是如果过分使用，类的数量会变得很多。

整理项目中的公共类会增加成本，但应该推动。

在项目中整备共用类是一个增加成本的因素，但是也是必须的。整备类的成本和团队成员理解规范所需的成本超过了其他因素。在项目中共用类的整备是为了提高质量，如果没有这个认识，就会变得沮丧。

在企业内部，应该以长期的展望来进行规划和整备。

从长远的角度看，也能够实现成本削减。