JAVA编码规范(精)

java编码规范文档# Java编码规范文档。

一、前言。

小伙伴们！当我们一起在Java的世界里畅游时，要是大家都按照一套约定俗成的编码规范来写代码，那我们的代码就像训练有素的军队一样，整齐又高效。

这份规范就是我们在Java编程旅程中的小指南，让我们的代码既容易理解，又方便维护。

二、命名规范。

# （一）包（package）命名。

1. 包名应该全部小写，用点（.）分隔单词。

就像你的小包裹要摆放得井井有条一样，包名也得规规矩矩。

例如：`com.example.myproject`，这看起来多清爽。

如果写成`Com.Example.MyProject`，那就像穿着奇装异服的士兵混在整齐的队伍里，很不协调。

# （二）类（class）命名。

1. 类名采用大驼峰命名法（UpperCamelCase），每个单词的首字母大写，不要包含下划线或者其他奇怪的符号。

这就好比给每个班级取一个正式又响亮的名字。

比如：`MyFirstClass`，而不是`my_first_class`或者`my first class`。

那些奇怪的写法就像给班级取个让人摸不着头脑的名字，可不好。

# （三）方法（method）命名。

1. 方法名采用小驼峰命名法（lowerCamelCase），第一个单词小写，后面每个单词首字母大写。

这就像给方法这个小助手取个清晰明了的名字，方便我们知道它是干什么的。

例如：`calculateSum`，而不是`Calculate_Sum`或者`CALCULATESUM`。

要是写成后面那种，就像一个小助手穿着奇装异服，你都不知道它是来帮忙做什么的。

# （四）变量（variable）命名。

1. 变量名同样采用小驼峰命名法。

变量就像一个个小盒子，我们得给它们取个能让人一眼就大概知道里面装什么东西的名字。

像`studentName`，你一看就知道这个变量可能是用来存学生名字的。

要是写成`student_name`或者`STUDENTNAME`，就有点让人迷糊啦。

• 类与接口的声明顺序:
• 静态成员变量 / Static Fields
• 静态初始化块 / Static Initializers
• 成员变量 / Fields
• 初始化块 / Initializers
• 构造器 / Constructors
• 静态成员方法 / Static Methods
• 成员方法 / Methods
/** * 〈一句话功能简述〉 * 〈功能详细描述〉 * @author [作者]（必须，使用汉语） * @see [相关类/方法]（可选） * @since [产品/模块版本] （可选） * @deprecated （可选） */
代码示 import java.blah.blahdy.Blah;
/** * Blah类处理订单业务流程. * 全部为静态变量和静态方法，对外提供统一接口。提供了订单保存， * 订单业务处理，查询等功能。 * * @author 张三 * @see OrderCmd * @since */ public class Blah extends SomeClass {}
4
技术部
命名规范
• 接口
采用完整的英文描述符说明接口封装，所有单词 的第一个字母大写。习惯上，名字前面加上大写 的 I, 遵守单一职责原则及接口隔离原则 比如：
interface Iraster
• 方法
方法采用完整的英文描述说明成员方法功 能，第一个单词尽可能采用一个生动的动词，尽 量满足见名知意且注意使用设计原则
技术部
20
异常注解
• 对于方法内部用throw语句抛出的异常，必须在方法的
注释中标明，对于所调用的其他方法所抛出的异常，选 择主要的在注释中说明。 对于非RuntimeException， 即throws子句声明会抛出的异常，必须在方法的注释中 标明。

第二章重要规范
（ 6 ）服务端，对关键交易请求要素进行日志输出，交易处理完成后 输出处理结果； （ 7 ）和外部系统交互，可将日志输出详细些，日志中尽量包括：请 求地址、内容、http响应码等状态信息、外部系统响应内容等信息； （ 8 ）数据库操作，捕获SQLException并对异常进行输出，可增加数 据库操作错误排查； （ 9 ）捕获异常后要对异常信息输出ERROR级别的日志，输出示例： logger.error(“XXX操作异常：”+e.getMassage(),e); （ 10 ） ERROR级别日志输出一般原则：对于由于系统原因造成业务 处理失败的事件，需要记录错误日志。非系统原因的业务处理失败， 不应该记录错误日志（推荐使用warn级别），避免错误日志过大，影 响紧急情况下的故障分析和诊断；
第三章命名规范
3、1包命名规则 java开发中产生的包分为两类，一类是与各业务系统相关的 包；另一类是与业务系统无关的、可公用的包。 规则：
包名应全部是小写字母; 包名中不能出现下划线和其他特殊字符; 第一个字母不能是数字。
示例：
与业务系统相关的包命名格式为：com. lianpay.<projectname>.<modulename>
其中：<projectname>为项目英文简称或缩写； <modulename>为模块英文名称或简称，如果无细分模块的话可 省略模块名。
与业务系统无关的、可公用的包：com. lianpay.share.<modulename>//所有项目通用
第三章命名规范
3.2类接口命名规则 规则：
类的名称应使用名词； 类和接口首字母必须大写，每个单词的首字母应大写（骆驼法 则）； 接口名称应以大写I开始，接口实现类以Impl结尾。

e.g.:
if (abc) {
}
for (int i = 0; i < 10; ++i) {
}
do {
} while (false);
try {
} catch (IOException e) {
} finally {
}
3.2 类命名不得使用拼音， 不得使用 My New Test 等无意义的词，要求类名见名知义。
3.3 类合理分包，如 cn.neiwang.emm.ui 中仅应放界面相关的类，不应该放日志模块。
3.4 package 行和 import 行间有且仅有一个空行。 import 结束和 类、接口的开始有且仅有一个空行。
Java编程规范
总体规则
(1) java 代码不得使用IDE自带的格式化，应该仅依赖于编码者去组织。
(2) 源码文件一律使用utf-8编码
(3) 不得因引用的包未使用、变量未使用等问题产生代码警告。
(4) 会显示在任意界面上的字符串严禁硬编码在java代码中，应由资源提供(国际化)
1. 基本规范
e.g.:
String fileName = userInfo.getFileName();
而不是:
String filename = userInfo.getFileName();
也不是：
String file_name = userInfo.getFileName();
1.9 不省略大括号。
e.g.:
if (sucess) {
return true;
}
而不是
if (sucess)