阿里java代码规约 阿里java代码规范考试

JAVA除了要满足命名规则之外,常量和变量一般还要遵循哪些命名惯例和约定?

1、package命名要求包含阿里java代码规约的所有字符均为小写阿里java代码规约，同时不能有特殊字符。

2、如果定义类的时候没有使用package,那么java就认为我们所定义的类位于默认包里面(default package)。

3、java中的打包机制是为了防止程序多个地方出现相同的名字而将局部程序限定在一块的机制

如阿里java代码规约：不同地区可能会存在 同名同姓的人阿里java代码规约，当要找其中一个人的时候就会产生混淆阿里java代码规约，为解决这个问题，我们不同地方的所有人（程序）分别打包。调用B的时候分别带上a.B或者是b.B。这样就不会出错了。打包其实就是新建了一个文件夹，然后把需要打包的程序放在这个文件夹里面。

————————————————

相关问答

Q1: java编码规范有哪些？

尽量使用完整的英文描述符，采用适用于相关领域的术语，采用大小写混合使名字可读。

JAVA代码规范：

(1)类名首字母应该大写。字段、方法以及对象（句柄）的首字母应小写。对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。例如：

ThisIsAClassName

thisIsMethodOrFieldName

若在定义中出现了常数初始化字符，则大写static final基本类型标识符中的所有字母。这样便可标志出它们属于编译期的常数。Java包（Package）属于一种特殊情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名称，如com，org，net或者edu等，全部都应小写（这也是Java1.1和Java1.2的区别之一）。

(2)为了常规用途而创建一个类时，请采取"经典形式"，并包含对下述元素的定义：equals()

hashCode()

toString()

clone()（implement Cloneable）

implement Serializable

(3)对于自己创建的每一个类，都考虑置入一个main()，其中包含了用于测试那个类的代码。为使用一个项目中的类，我们没必要删除测试代码。若进行了任何形式的改动，可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。

(4)应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。理想情况下，方法应简明扼要。若长度很大，可考虑通过某种方式将其分割成较短的几个方法。这样做也便于类内代码的重复使用（有些时候，方法必须非常大，但它们仍应只做同样的一件事情）。

(5)设计一个类时，请设身处地为客户程序员考虑一下（类的使用方法应该是非常明确的）。然后，再设身处地为管理代码的人考虑一下（预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单）。

(6)使类尽可能短小精悍，而且只解决一个特定的问题。下面是对类设计的一些建议：

一个复杂的开关语句：考虑采用"多形"机制

数量众多的方法涉及到类型差别极大的操作：考虑用几个类来分别实现

许多成员变量在特征上有很大的差别：考虑使用几个类

(7)让一切东西都尽可能地"私有"-private。可使库的某一部分"公共化"（一个方法、类或者一个字段等等），就永远不能把它拿出。若强行拿出，就可能破坏其他人现有的代码，使他们不得不重新编写和设计。若只公布自己必须公布的，就可放心大胆地改变其他任何东西。在多线程环境中，隐私是特别重要的一个因素-只有private字段才能在非同步使用的情况下受到保护。

(8)谨惕"巨大对象综合症。对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的程序，再把它嵌入一个或两个巨大的对象里。根据编程原理，对象表达的应该是应用程序的概念。

Q2: 如何评价阿里巴巴java编码规范认证考试

“阿里巴巴编码规范”是阿里云大学基于《阿里巴巴Java开发手册》打造的认证，用于考察以及让开发者自查对规范的掌握程度。《阿里巴巴Java开发手册》是阿里内部Java工程师所遵循的开发规范，涵盖编程规约、单元测试规约、异常日志规约、MySQL规约、工程规约、安全规约等，这是近万名阿里Java技术精英的经验总结，并经历了多次大规模一线实战检验及完善。该手册于2017年2月份推出以来，引起了业界广泛关注，目前该手册已有几十万的下载量，已被很多中小型公司用来作为内部的开发规范。如果你掌握了这些规范，那么你在进入阿里后，就不会因为编码习惯不同而增加协同的成本，从而可以更快融入团队。

Q3: 为什么阿里工程师代码写的好？看看他的代码规范就知道了

曾经与一位从阿里出来的Java工程师一起工作过一段时间，他的技术说不上非常厉害， 但是，他的代码写的的非常好，凡是他做的功能很少出现Bug 。我就很好奇，于是经常向他请教一些代码设计的原则，然后他告诉了我阿里Java手册。并且，他将这个手册进行了修改，也成为了我司Java程序员的开发手册。 这篇文章就让我们看一看这个手册中比较重要的原则。

【强制】 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。

反例：_name / __name / $name / name_ / name$ / name__

【强制】 类型与中括号紧挨相连来表示数组。

正例：定义整形数组 int[] arrayDemo; 反例：在 main 参数中，使用 String args[]来定义。

【强制】 POJO 类中布尔类型变量都不要加 is 前缀，否则部分框架解析会引起序列化错误。

说明：表达是与否的值采用 is_xxx 的命名方式，所以，需要在 设置从 is_xxx 到 xxx 的映射关系。

反例：定义为基本数据类型 Boolean isDeleted 的属性，它的方法也是 isDeleted()， RPC 框架在反向解 析的时候，“误以为”对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。

【推荐】 在常量与变量的命名时，表示类型的名词放在词尾，以提升辨识度。

【推荐】 接口类中的方法和属性不要加任何修饰符号(public 也不要加)，保持代码的简洁 性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定 是与接口方法相关，并且是整个应用的基础常量。

正例:接口方法签名 void commit();

接口基础常量 String COMPANY = "alibaba";

反例:接口方法定义 public abstract void f();

说明:JDK8 中接口允许有默认实现，那么这个 default 方法，是对所有实现类都有价值的默认实现。

【参考】 枚举类名带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

说明：枚举其实就是特殊的类，域成员均为常量，且构造方法被默认强制是私有。

正例:枚举名字为 ProcessStatusEnum 的成员名称:SUCCESS / UNKNOWN_REASON。

【参考】 各层命名规约:

1) 获取单个对象的方法用 get 做前缀。

2) 获取多个对象的方法用 list 做前缀，复数形式结尾如:listObjects。 3) 获取统计值的方法用 count 做前缀。

4) 插入的方法用 save/insert 做前缀。

5) 删除的方法用 remove/delete 做前缀。

6) 修改的方法用 update 做前缀。

1) 数据对象:xxxDO，xxx 即为数据表名。

2) 数据传输对象:xxxDTO，xxx 为业务领域相关的名称。

3) 展示对象:xxxVO，xxx 一般为网页名称。

4) POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

【强制】 不允许任何魔法值(即未经预先定义的常量)直接出现在代码中。

【强制】 避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析 成本，直接用类名来访问即可。

【强制】 相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。

说明：可变参数必须放置在参数列表的最后。(提倡同学们尽量不用可变参数编程)

【强制】 所有整型包装类对象之间值的比较，全部使用equals方法比较。

说明：对于 Integer var = ? 在-128 至 127 范围内的赋值，Integer 对象是在 IntegerCache.cache 产 生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行判断，但是这个区间之外的所有数 据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用 equals 方法进行判断。

关于基本数据类型与包装数据类型的使用标准如下:

说明： POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值 ，任何 NPE 问题，或 者入库检查，都由使用者来保证。

正例：数据库的查询结果可能是 null，因为自动拆箱，用基本数据类型接收有 NPE 风险。

反例： 比如显示成交总额涨跌情况，即正负 x%，x 为基本数据类型，调用的 RPC 服务，调用不成功时， 返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线 。所以包装数据类型的 null 值，能 够表示额外的信息，如:远程调用失败，异常退出。

【强制】 POJO 类必须写 toString 方法。

使用 IDE 中的工具:source generate toString 时，如果继承了另一个 POJO 类，注意在前面加一下 super.toString。

说明： 在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题。

【强制】 关于hashCode和equals的处理，遵循如下规则：

说明：String 已覆写 hashCode 和 equals 方法，所以我们可以愉快地使用 String 对象作为 key 来使用。

【强制】 线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

说明：线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问 题。 如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

【强制】 线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

以上规范在设计代码中，是比较重要的原则。如果编写代码的过程中，可以依照以上原则，那代码的可读性和可维护性将大大提升

Q4: 为什么阿里代码规约要求避免使用 Apache BeanUtils 进行属性复制

有一次开发过程中，刚好看到小伙伴在调用 set 方法，将数据库中查询出来的 Po 对象的 属性拷贝 到 Vo 对象中，类似这样：

可以看出，Po 和 Vo 两个类的字段绝大部分是一样的，我们一个个地调用 set 方法只是做了一些重复的冗长的操作。 这种操作非常容易出错，因为对象的属性太多，有可能会漏掉一两个，而且肉眼很难察觉 。

类似这样的操作，我们很容易想到可以通过反射来解决。其实，如此普遍通用的功能，一个 BeanUtils 工具类就可以搞定了。

于是我建议这位小伙伴了解一下 BeanUtils，后来他使用了 Apache BeanUtils.copyProperties 进行属性拷贝，这为程序 挖了一个坑 ！

当我们开启阿里代码扫描插件时，如果你使用了 Apache BeanUtils.copyProperties 进行属性拷贝，它会给你一个 非常严重的警告 。因为， Apache BeanUtils性能较差，可以使用 Spring BeanUtils 或者 Cglib BeanCopier 来代替 。

看到这样的警告，有点让人有点不爽。大名鼎鼎的 Apache 提供的包，居然会存在 性能问题 ，以致于阿里给出了严重的警告。

那么，这个 性能问题究竟是有多严重 呢？毕竟，在我们的应用场景中，如果只是很微小的性能损耗，但是能带来非常大的便利性，还是可以接受的。

带着这个问题。我们来做一个实验，验证一下。

如果对具体的测试方式没有兴趣，可以 跳过直接看结果 哦~

测试方法接口和实现定义

首先，为了测试方便，让我们来定义一个接口，并提供各种实现：

单元测试

然后写一个参数化的单元测试：

测试结果

结果表明， Cglib 的 BeanCopier 的拷贝速度是最快的 ，即使是百万次的拷贝也只需要 10 毫秒！ 相比而言，最差的是 Commons 包的 BeanUtils.copyProperties 方法，100 次拷贝测试与表现最好的 Cglib 相差 400 倍 之多。百万次拷贝更是出现了 2600 倍的性能差异！

结果真是让人大跌眼镜。

但是它们为什么会有这么大的差异呢？

原因分析

查看源码，我们会发现 CommonsBeanUtils 主要有以下几个耗时的地方：

具体的性能和源码分析，可以参考这几篇文章：

几种copyProperties工具类性能比较：

CGLIB中BeanCopier源码实现：

Java Bean Copy框架性能对比：

除了性能问题之外，在使用 CommonsBeanUtils 时还有 其他的坑 需要特别小心！

包装类默认值

在进行属性拷贝时，低版本CommonsBeanUtils 为了解决Date为空的问题会导致为目标对象的 原始类型的包装类属性赋予初始值 ，如 Integer 属性默认赋值为 0，尽管你的来源对象该字段的值为 null。

这个在我们的 包装类属性为 null 值时有特殊含义的场景 ，非常容易踩坑！例如搜索条件对象，一般 null 值表示该字段不做限制，而 0 表示该字段的值必须为0。

改用其他工具时

当我们看到阿里的提示，或者你看了这篇文章之后，知道了 CommonsBeanUtils 的性能问题，想要改用 Spring 的 BeanUtils 时， 要特别小心 ：

从方法签名上可以看出，这 两个工具类的名称相同，方法名也相同，甚至连参数个数、类型、名称都相同 。但是 参数的位置是相反的 。因此，如果你想更改的时候，千万要记得，将 target 和 source 两个参数也调换过来！

关于阿里java代码规约和阿里java代码规范考试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。