1、命名规约
【强制】类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名）DO / BO / DTO / VO等。
正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。
正例： localValue / getHttpMessage() / inputUserId
【强制】抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。
【强制】POJO类中布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型boolean isSuccess；的属性，它的方法也是isSuccess()，RPC框架在反向解析的时候，“以为”对应的属性名称是success，导致属性获取不到，进而抛出异常。
【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例： 应用工具类包名为com.alibaba.open.util、类名为MessageUtils（此规则参考spring的框架结构）
【推荐】如果使用到了设计模式，建议在类名中体现出具体模式。 说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计思想。
public class OrderF
public class LoginP
public class ResourceO
【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名：void f(); 接口基础常量表示：String COMPANY = "alibaba";
反例：接口方法定义：public abstract void f(); 说明：JDK8中接口允许有默认实现，那么这个default方法，是对所有实现类都有价值的默认实现。
接口和实现类的命名有两套规则：
1）【强制】对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。
正例：CacheServiceImpl实现CacheService接口。
2） 【推荐】 如果是形容能力的接口名称，取对应的形容词做接口名（通常是–able的形式）。
正例：AbstractTranslator实现 Translatable。
【参考】各层命名规约：
A) Service/DAO层方法命名规约
1） 获取单个对象的方法用get做前缀。
2） 获取多个对象的方法用list做前缀。
3） 获取统计值的方法用count做前缀。
4） 插入的方法用save（推荐）或insert做前缀。
5） 删除的方法用remove（推荐）或delete做前缀。
6） 修改的方法用update做前缀。
B) 领域模型命名规约
1） 数据对象：xxxDO，xxx即为数据表名。
2） 数据传输对象：xxxDTO，xxx为业务领域相关的名称。
3） 展示对象：xxxVO，xxx一般为网页名称。
4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。
2、常量定义
【强制】不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId； cache.put(key, value);
【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
1） 跨应用共享常量：放置在二方库中，通常是client.jar中的constant目录下。
2） 应用内共享常量：放置在一方库的modules中的constant目录下。
反例：易懂变量也要统一定义成应用内共享常量，两位攻城师在两个类中分别定义 了表示“是”的变量： 类A中：public static final String YES = "yes"; 类B中：public static final String YES = "y"; A.YES.equals(B.YES)，预期是true，但实际返回为false，导致产生线上问题。
3） 子工程内部共享常量：即在当前子工程的constant目录下。
4） 包内共享常量：即在当前包下单独的constant目录下。
5） 类内共享常量：直接在类内部private static final定义。
3、格式规约
【强制】if/for/while/switch/do等保留字与左右括号之间都必须加空格。
【强制】缩进采用4个空格，禁止使用tab字符。
说明： 如果使用 tab 缩进，必须设置 1个 tab 为 4个空格。
IDEA 设置 tab 为 4个空格时， 请勿勾选 Use tab character ；而在 eclipse 中，必须勾选 insert spaces for tabs 。
【强制】方法参数在定义和传入时，多个参数逗号后边必须加空格。 正例：下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");
【强制】IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式，不要使用windows格式。
4、OOP规约
【强制】所有的覆写方法，。
反例：getObject()与get0bject()的问题。一个是字母的O，一个是数字的0，。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编译报错。
【强制】对外暴露的接口签名，原则上不允许修改方法签名，避免对接口调用方产生影响。，并清晰地说明采用的新接口或者新服务是什么。
【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。
正例： "test".equals(object);
反例： object.equals("test");
说明：推荐使用java.util.Objects#equals （JDK7引入的工具类）
【强制】所有的相同类型的包装类对象之间值的比较，全部使用equals方法比较。
说明：对于Integer var=?在-128至127之间的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，这个区间内的Integer值可以直接使用==进行判断，
但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用equals方法进行判断。
【强制】关于基本数据类型与包装数据类型的使用标准如下：
1） 所有的POJO类属性必须使用包装数据类型。
2） RPC方法的返回值和参数必须使用包装数据类型。
3） 所有的局部变量【推荐】使用基本数据类型。
说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。
反例：比如显示成交总额涨跌情况，即正负x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示：0%，这是不合理的，应该显示成中划线-。所以包装数据类型的null值，能够表示额外的信息，如：远程调用失败，异常退出。
【强制】定义DO/DTO/VO等POJO类时，不要设定任何属性默认值。
反例：POJO类的gmtCreate默认值为new Date();但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。
【强制】POJO类必须写toString方法。
使用IDE的中工具：source& generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。
说明：在方法执行抛出异常时，可以直接调用POJO的toString()方法打印其属性值，便于排查问题。
【推荐】使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛IndexOutOfBoundsException的风险。
String str = "a,b,c,,";
String[] ary = str.split(",");
//预期大于3，结果是3
System.out.println(ary.length);
【推荐】 类内方法定义顺序依次是：公有方法或保护方法 & 私有方法 & getter/setter方法。
说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为方法信息价值较低，所有Service和DAO的getter/setter方法放在类体最后。
【推荐】final可提高程序响应效率，声明成final的情况： 1） 不需要重新赋值的变量，包括类属性、局部变量。 2） 对象参数前加final，表示不允许修改引用的指向。 3） 类方法确定不允许被重写。
【推荐】类成员与方法访问控制从严：
1） 如果不允许外部直接通过new来创建对象，那么构造方法必须是private。
2） 工具类不允许有public或default构造方法。
3） 类非static成员变量并且与子类共享，必须是protected。
4） 类非static成员变量并且仅在本类使用，必须是private。
5） 类static成员变量如果仅在本类使用，必须是private。
6） 若是static成员变量，必须考虑是否为final。
7） 类成员方法只供类内部调用，必须是private。
8） 类成员方法只对继承类公开，那么限制为protected。
说明：任何类、方法、参数、变量，严控访问范围。过宽泛的访问范围，不利于模块解耦。思考：如果是一个private的方法，想删除就删除，可是一个public的Service方法，或者一个public的成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作用域太大，如果无限制的到处跑，那么你会担心的。
5、集合处理
待续。。。
阅读(...) 评论()在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
标签：至少1个，最多5个
昨日（10/14）日，阿里巴巴在杭州云栖大会上，正式发布了由阿里巴巴 P3C 项目组，经过 247 天的持续研发，正式发布众所期待的 《阿里巴巴 Java 开发规约》的扫描插件！
P3C 是世界知名的反潜机，专门对付水下潜水艇，寓意是扫描出所有潜在的代码隐患。这个项目组是阿里巴巴开发爱好者自发组织的虚拟项目组，把《阿里巴巴 Java 开发规约》强制条目转化自动插件，并实现部分的自动编码。
该插件已经在 Github 上开源，有兴趣的可以直接去看看。
或者在Github直接搜索p3c
二、该插件的主要功能
该插件主要是对今年发布的《阿里巴巴 Java 开发规约》的一个延伸，它以一个 IDE 的插件存在，可以自动对手册中的 Java 不规范的问题进行提示。现在主要支持（IDEA、Eclipse），Android Studio 是基于 IDEA 的，所以也是支持 Android 开发人员的。
该插件在扫描代码后，会将不符合规约的代码按照 Blocker/Critical/Major 三个等级显示在下方，甚至在 IDEA 上，还可以基于 Inspection 机制提供了实时检测的功能，编写代码的同时也能快速发现不规范的代码。而对于历史代码，部分规则实现了批量一键修复的功能，为首次在成熟项目上，使用插件，做了非常友善的支持。
三、如何安装
本着 Android 开发的视角，这里只介绍如何在 Android Studio 中使用 Alibaba Java Coding Guidelines（以下简称阿里规约插件）。其他工具，请翻阅文档。
3.1 搜索插件
依次选择：Setting && Plugins && Browse repositories .
3.2 安装插件
搜索关键字『alibaba』，并在结果中，找到 Alibaba Java Coding Guidelines 并安装。
安装完成之后，会有提示需要重启 Android Studio，我们点击 restart 按钮就可以帮我们自动重启，当然我们手动重启也行。
四、如何使用
4.1 切换语言
阿里规约插件的使用非常的简单，并且本身插件就是国人开发完成，所以对中文的支持非常的好。
安装之后，它会默认使用你当前设备选择的语言环境，进行配置语言，当然你也可以自行切换语言，暂时仅支持 中文 和 英语。
你可以在 Tools && Alibaba Coding Guidelines && Switch language to Xxx 进行切换。
这里切换之后，也需要重启 IDEA 才可以生效。
4.2 Inspections 支持
Inspections 相信大家应该都不陌生，它会自动在我们编码的阶段，进行快速灵活的静态代码分析，自动检测编译器和运行时错误，并提示开发人员再编译之前就进行有效的改正和改进。
这里举个简单的例子。
可以看到，它会个我指出我这里编写不规范的地方，如果想要查看更多细节，点击 more 按钮即可。
当然，所有的规范，都可以再 Inspections 中查看到。
在 Inspections 中，以 All-Check 区分，以下是它支持的所有检查，有兴趣可以一个个点击查看细节，右侧为检查出问题之后的提示信息，如果不想要的检测条件，还可以将它反选掉。
4.3 代码静态分析
阿里规约插件，除了支持 Inspections 之外，还可以对现有项目进行静态代码分析。
它分析的结果，会以 Blocker/Critical/Major 三个级别进行区分。最终检测出来的效果也非常的直观，如果你是当前插件语言是中文，基本上一眼就看出来哪里有问题，并给出了修复建议。
4.4 VCS 支持
Android Stuido 中，默认提供 VCS 支持，我们只需要简单的配置，就可以支持 Git、SVN 等。
Android Studio 中，配合 Git 使用，不了解的可以看看我之前的文章。《》
而阿里规约插件，同时也支持这部分的校验，它可以在我们提交代码之前，对我们本次提交的代码进行规约检测。
这个功能，在我看来还是非常的有用的，符合检测结果之后，自己代码质量和同队 Code Review 的效率都会提高。
五、规约源码
最后说点题外话，简单看看规约的源码是什么结构。
从结构上来看，不同的插件分别用不同的项目在维护，这也是毋庸置疑的，本身也不通用。
有趣的是，阿里规约插件是完全使用 Kotlin 进行开发的。
可以看到，结构也非常的清晰，对 inspection 的支持，在 compatible/inspection 和 inspection 中，VCS 的支持，在 vcs 中。
细节我们就不多看了，有兴趣就去阅读源码吧。
阿里规约插件，插件的主要情况，本文已经讲解清楚了。
但是它主要还是基于之前发布的 《阿里巴巴 Java 开发手册 终极版》，建议还是提前阅读一下本文档，可以在承香墨影中回复『阿里规约』，即可查看完整的文档。
今天在承香墨影公众号的后台，回复『成长』。我会送你一些我整理的学习资料，包含：Android反编译、算法。Web项目源码。
推荐阅读：
点赞或者分享吧~
11 收藏&&|&&59
你可能感兴趣的文章
14 收藏，1.9k
83 收藏，22.1k
2 收藏，845
本作品采用 署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可
idea已安装
idea已安装
业界标杆。。。
业界标杆。。。
分享到微博？
我要该，理由是：}