Java 开发手册

目录 一、编程规约.......................................................................................................................................... 2

(一) 命名规约................................................................................................................................................... 2

(二) 常量定义................................................................................................................................................... 4

(三)格式规约..................................................................................................................................................... 4

(四) OOP 规约................................................................................................................................................... 5

(五) 集合处理................................................................................................................................................... 9

(六) 并发处理................................................................................................................................................. 11

(七) 控制语句................................................................................................................................................. 12

(八) 其它........................................................................................................................................................ 13

二、日志&SQL..................................................................................................................................................... 14

(一) 异常处理................................................................................................................................................. 14

(二) SQL 规约.................................................................................................................................................. 15

 

 

 

Java 开发手册

 

 

版本号

 

 

 

制定团队

 

 

 

更新日期

 

 

 

备注

 

 

1.0.0

 

Java开发组

 

2017.2.10

 

红色标出的为必须遵守

 

 

 

一、编程规约

() 命名规约

 

  1. 【强制】 代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。反例: _name / __name / $Object / name_ / name$ / Object$

 

  1. 【强制】 代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。 说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式 也

要避免采用。  

 

反例: DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3  正例: alibaba / taobao / youku / hangzhou 等国际通用的名称,可视同英文。  

 

  1. 【强制】类名使用 UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外:(领域模型 的相关命名)DO / BO / DTO / VO 等。

 

正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例: macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion  

 

  1. 【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必须遵从

驼峰形式。  

 

正例: localValue / getHttpMessage() / inputUserId  

 

  1. 【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。正例: MAX_STOCK_COUNT

 

反例: MAX_COUNT  

 

  1. 【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾;测试类 命名以它要测试的类的名称开始,以 Test 结尾。

 

正例: AuthorizationException

 

 

  1. 【强制】中括号是数组类型的一部分,数组定义如下:String[] args; 反例:请勿使用

String args[]的方式来定义。 

 

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

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

 

  1. 【强制】包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。 正例: 应用工具类包名为alibaba.open.util、类名为MessageUtils(此规则参考spring的框架结构)

 

  1. 【强制】杜绝完全不规范的缩写,避免望文不知义。 反例: AbstractClass“缩写”命名成

AbsClass;condition“缩写”命名成 condi,此类随意缩写严重降低了代码的可阅读性。 

 

  1. 【推荐】如果使用到了设计模式,建议在类名中体现出具体模式。 说明:将设计模式体现在名字中,有利于阅读者快速理解架构设计思想。

正例:public class OrderFactory;  public class LoginProxy; 

public class ResourceObserver; 

 

  1. 接口和实现类的命名有两套规则:
    1. 【强制】对于Service和DAO类,基于SOA的理念,暴露出来的服务一定是接口,内部的实现类用Impl的后缀与接口区别。 正例:CacheServiceImpl实现CacheService接口。
    2. 【推荐】 如果是形容能力的接口名称,取对应的形容词做接口名(通常是–able的形式)。 正例:AbstractTranslator实现 Translatable。

 

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

说明:枚举其实就是特殊的常量类,且构造方法被默认强制是私有。 正例:枚举名字:

DealStatusEnum,成员名称:SUCCESS / UNKOWN_REASON。 

 

  1. 【参考】各层命名规约:
    1. Service/DAO层方法命名规约
      1. 获取单个对象的方法用get做前缀。
      2. 获取多个对象的方法用list做前缀。
      3. 获取统计值的方法用count做前缀。
      4. 插入的方法用save(推荐)或insert做前缀。
      5. 删除的方法用remove(推荐)或delete做前缀。
      6. 修改的方法用update做前缀。
    2. 领域模型命名规约
      1. 数据对象:xxxDO,xxx即为数据表名。
      2. 数据传输对象:xxxDTO,xxx为业务领域相关的名称。
      3. 展示对象:xxxVO,xxx一般为网页名称。
      4. POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。

 

  1. 【强制】import不要使用通配符 即,不要出现类似这样的import语句:import java.util.*;

 

 

  1. 【强制】一般情况下,一行长代码为了避免超出列限制(80或100个字符)而被分为多行,我们称之为自动换行(line-wrapping),分割处必须为一个语意结束的地方,让人看代码不能引起歧义。

 

  1. 每次只声明一个变量,不要使用组合声明,比如int a, b;。

 

(二) 常量定义

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

反例: String key="Id#taobao_"+tradeId;  cache.put(key, value); 

 

  1. 【推荐】不要使用一个常量类维护所有常量,应该按常量功能进行归类,分开维护。如:缓存相关的常量放在类:CacheConsts下;系统配置相关的常量放在类:ConfigConsts下。 说明:大而全的常量类,非得使用查找功能才能定位到修改的常量,不利于理解和维护。

 

 

(三)格式规约

  1. 【强制】大括号的使用约定。如果是大括号内为空,则简洁地写成{}即可,不需要换行;如果是非空代码块则:
    1. 左大括号前不换行。
    2. 左大括号后换行。
    3. 右大括号前换行。
    4. 右大括号后还有else等代码则不换行;表示终止右大括号后必须换行。

 

 

  1. 【强制】任何运算符左右必须加一个空格。 说明:运算符包括赋值运算符=、逻辑运算符

&&、加减乘除符号、三目运行符等。 

 

 

  1. 【强制】缩进采用4个空格,禁止使用tab字符。

正例: (涉及1-5点)

public static void main(String args[]) {

                      // 缩进4个空格

                      String say = "hello";

  // 运算符的左右必须有一个空格  int flag = 0;

  // 关键词if与括号之间必须有一个空格,括号内的f与左括号,0与右括号不需要空格  if (flag == 0) {

                            System.out.println(say);

                      }

  // 左大括号前加空格且不换行;左大括号后换行  if (flag == 1) {

                            System.out.println("world");

                            // 右大括号前换行,右大括号后有else,不用换行

                      } else {

                            System.out.println("ok");

                            // 在右大括号后直接结束,则必须换行

                      }

}

 

 

 

  1. 【强制】IDE的text file encoding设置为UTF-8;  
  2. 【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。

           正例: 

int a = 3;  long b = 4L;  float c = 5F; 

StringBuffer sb = new StringBuffer(); 

说明:增加sb这个变量,如果需要对齐,则给a、b、c都要增加几个空格,在变量比较多的情况下,是一种累赘的事情。

 

 

  1. 【推荐】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。 说明:没有必要插入多行空格进行隔开。

 

 

(四) OOP 规约

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

                public static String PARM = "testParm"; 

           

                 public static void main(String[] args) {

                       正例:

                       String correct = Test.PARM;

                       反例:

                       Test test = new Test();

                       String error = test.PARM;

               

                 }

 

  1. 【强制】所有的覆写方法,必须加@Override注解。 反例:getObject()与get0bject()的问题。一个是字母的O,一个是数字的0,加@Override可以准确判断是否覆盖成功。另外,如果在抽象类中对方法签名进行修改,其实现类会马上编译报错。

 

 

  1. 【强制】相同参数类型,相同业务含义,才可以使用Java的可变参数,避免使用Object。说明:可变参数必须放置在参数列表的最后。(提倡同学们尽量不用可变参数编程) 正

例:public User getUsers(String type, Integer... ids) 

 

 

  1. 【强制】对外暴露的接口签名,原则上不允许修改方法签名,避免对接口调用方产生影响。

接口过时必须加@Deprecated注解,并清晰地说明采用的新接口或者新服务是什么。 

 

 

 

  1. 【强制】不能使用过时的类或方法。 说明:net.URLDecoder 中的方法decode(String encodeStr) 这个方法已经过时,应该使用双参数decode(String source, String encode)。接口提供方既然明确是过时接口,那么有义务同时提供新的接口;作为调用方来说,有义务去考证过时方法的新实现是什么。

 

  1. 【强制】Object的equals方法容易抛空指针异常,应使用常量或确定有值的对象来调用 equals。

      正例: "test".equals(object);         反例: object.equals("test"); 

 

  1. 【强制】所有的相同类型的包装类对象之间值的比较,全部使用equals方法比较。 说明:对于Integer var=?在-128至127之间的赋值,Integer对象是在cache产生,会复用已有对象,这个区间内的Integer值可以直接使用==进行判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑,推荐使用equals方法进行判断。

 

比如 Integer i=100,j=100;

那么j实际上就是指向的i,因为i缓存了

 

如果Integer i=200,j=200;

这时候不会缓存,会新建一个对象200,

 

所以第一次 i==j为真

第二次 i==j为假

 

 

  1. 【强制】关于基本数据类型与包装数据类型的使用标准如下:
    1. 所有的POJO类属性必须使用包装数据类型。
    2. RPC方法的返回值和参数必须使用包装数据类型。
    3. 所有的局部变量【推荐】使用基本数据类型。 说明:POJO类属性没有初值是提醒使用者在需要使用时,必须自己显式地进行赋值,任何NPE问题,或者入库检查,都由使用者来保证。 正例:数据库的查询结果可能是null,因为自动拆箱,用基本数据类型接收有NPE风险。 反例:比如显示成交总额涨跌情况,即正负x%,x为基本数据类型,调用的RPC服务,调用不成功时,返回的是默认值,页面显示:0%,这是不合理的,应该显示成中划线-。所

以包装数据类型的null值,能够表示额外的信息,如:远程调用失败,异常退出。 

 

 

public static int PARM; 

     

      public static void main(String[] args) {

         

            System.out.println(PARM);

         

                        }

此默认值为0,并不是为空。

 

  1. 【强制】定义DO/DTO/VO等POJO类时,不要设定任何属性默认值。 反例:POJO类的 gmtCreate默认值为new Date();但是这个属性在数据提取时并没有置入具体值,在更新其它字段时又附带更新了此字段,导致创建时间被修改成当前时间。

 

  1. 【强制】序列化类新增属性时,请不要修改serialVersionUID字段,避免反序列失败;如果完全不兼容升级,避免反序列化混乱,那么请修改serialVersionUID值。 说明:注意 serialVersionUID不一致会抛出序列化运行时异常。

原因请看http://www.cnblogs.com/guanghuiqq/archive/2012/07/18/2597036.html

 

  1. 【强制】构造方法里面禁止加入任何业务逻辑,如果有初始化逻辑,请放在init方法中。

 

  1. 【推荐】POJO类必须写toString方法。使用IDE的中工具:source> generate toString时,如果继承了另一个POJO类,注意在前面加一下toString。 说明:在方法执行抛出异常时,可以直接调用POJO的toString()方法打印其属性值,便于排查问题。

 

正例:

public class TestObject implements Serializable {

            /** * */

            private static final long serialVersionUID = 6977402643848374752L;

            int id;

            String name;

     

            public TestObject(int id, String name) {

                  this.id = id;

                  this.name = name;

            }

 

            public String toString() {

                  return "DATA: " + id + " " + name;

            }

}

 

  1. 【推荐】使用索引访问用String的split方法得到的数组时,需做最后一个分隔符后有无内容的检查,否则会有抛IndexOutOfBoundsException的风险。

说明: 

String str = "a,b,c,,"; 

String[] ary = str.split(","); 

//预期大于3,结果是3 

System.out.println(ary.length); 

  1. 【推荐】当一个类有多个构造方法,或者多个同名方法,这些方法应该按顺序放置在一起,便于阅读。

 

  1. 【推荐】 类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter/setter方法。 说明:公有方法是类的调用者和维护者最关心的方法,首屏展示最好;保护方法虽然只是子类关心,也可能是“模板设计模式”下的核心方法;而私有方法外部一般不需要特别关心,是一个黑盒实现;因为方法信息价值较低,所有Service和DAO的getter/setter方法放在类体最后。

 

  1. 【推荐】setter方法中,参数名称与类成员变量名称一致,成员名=参数名。在 getter/setter方法中,尽量不要增加业务逻辑,增加排查问题的难度。

反例: 

public Integer getData(){  if(true) { 

return data + 100; 

} else { 

return data - 100; 

}

 

  1. 【推荐】循环体内,字符串的联接方式,使用StringBuilder的append方法进行扩展。 反例:

String str = "start";  for(int i=0; i<100; i++){  str = str + "hello"; 

说明:反编译出的字节码文件显示每次循环都会new出一个StringBuilder对象,然后进行 append操作,最后通过toString方法返回String对象,造成内存资源浪费。

 

  1. 【推荐】final可提高程序响应效率,声明成final的情况:
    1. 不需要重新赋值的变量,包括类属性、局部变量。
    2. 对象参数前加final,表示不允许修改引用的指向。
    3. 类方法确定不允许被重写。

 

  1. 【推荐】慎用Object的clone方法来拷贝对象。 说明:对象的clone方法默认是浅拷贝,若想实现深拷贝需要重写clone方法实现属性对象的拷贝。 (在没有必要的情况下尽量不要使用clone)

说明:http://blog.csdn.net/centre10/article/details/6847973

 

  1. 【推荐】类成员与方法访问控制从严:
    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的成员变量,删除一下,不得手心冒点汗吗?变量像自己的小孩,尽量在自己的视线内,变量作用域太大,如果无限制的到处跑,那么你会担心的。 

 

 

(五) 集合处理

  1. 【强制】关于hashCode和equals的处理,遵循如下规则: 1) 只要重写equals,就必须重写hashCode。
  1. 因为Set存储的是不重复的对象,依据hashCode和equals进行判断,所以Set存储的对象必须重写这两个方法。
  2. 如果自定义对象做为Map的键,那么必须重写hashCode和equals。

 

正例:String重写了hashCode和equals方法,所以我们可以非常愉快地使用String对象作为 key来使用。 

 

说明:HashMap中,如果要比较key是否相等,要同时使用这两个函数!因为自定义的类的

hashcode()方法继承于Object类,其hashcode码为默认的内存地 址,

这样即便有相同含义的两个对象,比较也是不相等的,例如,生成了两个“羊”对象,正常理解这两个对象应该是相等的,但如果你不重写 hashcode()方法的话,比较是不相等的!

HashMap中的比较key是这样的,   先求出key的hashcode(),比较其值是否相等,  若相等再比较equals(),若相等则认为他们是相等 的。若equals()不相等则认为他们不相等。如果只重写hashcode()不重写equals()方法,当比较equals()时只是看他们是否为 同一对象(即进行内存地址的比较),所以必定要两个方法一起重写。HashMap用来判断key是否相等的方法,其实是调用了HashSet判断加入元素是否相等。

    

  1. 【强制】 ArrayList的subList结果不可强转成ArrayList,否则会抛出ClassCastException 异常:util.RandomAccessSubList cannot be cast to java.util.ArrayList ; 说明:subList 返回的是 ArrayList 的内部类 SubList,并不是 ArrayList ,而是 ArrayList 的一个视图,对于SubList子列表的所有操作最终会反映到原列表上。

 

  1. 【强制】 在subList场景中,高度注意对原集合元素个数的修改,会导致子列表的遍历、增加、删除均产生ConcurrentModificationException 异常。  
  2. 【强制】使用集合转数组的方法,必须使用集合的toArray(T[] array),传入的是类型完全一样的数组,大小就是size()。 反例:直接使用toArray无参方法存在问题,此方法返回值只能是Object[]类,若强转其它类型数组将出现ClassCastException错误。

List<String> list = new ArrayList<String>(2);  list.add("guan");  list.add("bao"); 

正例:

String[] array = new String[list.size()];  array = list.toArray(array); 

反例:

String[] arrayError = (String[]) list.toArray();

说明:使用toArray带参方法,入参分配的数组空间不够大时,toArray方法内部将重新分配内存空间,并返回新数组地址;如果数组元素大于实际所需,下标为[ list.size() ]的数组元素将被置为null,其它数组元素保持原值,因此最好将方法入参数组大小定义与集合元素个数一致。

 

  1. 【强制】使用工具类asList()把数组转换成集合时,不能使用其修改集合相关的方法,它的add/remove/clear方法会抛出UnsupportedOperationException异常。 说明: asList的返回对象是一个Arrays内部类,并没有实现集合的修改方法。Arrays.asList体现的是适配器模式,只是转换接口,后台的数据仍是数组。

String[] str = new String[] { "a", "b" };  List list = Arrays.asList(str); 

第一种情况:list.add("c"); 运行时异常。 

第二种情况:str[0]= "gujin"; 那么list.get(0)也会随之修改。 

 

  1. 【强制】泛型通配符<? extends T>来接收返回的数据,此写法的泛型集合不能使用add方法。

说明:苹果装箱后返回一个<? extends Fruits>对象,此对象就不能往里加任何水果,包括苹果。 

List<Apple> listApple = new ArrayList<Apple>();

            listApple.add(new Apple());

         

        List<? extends Fruits> list = listApple;          System.out.println(list.size());      list.add(new Apple());//这里报错

                      System.out.println(list.size());

 

 

 

  1. 【强制】不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式,如果并发操作,需要对Iterator对象加锁。 反例:

List<String> a = new ArrayList<String>(); 

a.add("1"); 

a.add("2");  for (String temp : a) { 

if("1".equals(temp)){ 

a.remove(temp); 

说明:以上代码的执行结果肯定会出乎大家的意料,那么试一下把“1”换成“2”,会是同样的结果吗? 正例: 

Iterator<String> it = a.iterator();  while(it.hasNext()){  String temp = it.next(); 

if(删除元素的条件){  it.remove(); 

}

 

 

  1. 【强制】 在JDK7版本以上,Comparator要满足自反性,传递性,对称性,不然

Arrays.sort,Collections.sort会报IllegalArgumentException异常。  说明: 

  1. 自反性:x,y的比较结果和y,x的比较结果相反。
  2. 传递性:x>y,y>z,则x>z。
  3. 对称性:x=y,则x,z比较结果和y,z比较结果相同。 反例:下例中没有处理相等的情况,实际使用中可能会出现异常:

new Comparator<Student>() { 

@Override  public int compare(Student o1, Student o2) {  return o1.getId() > o2.getId() ? 1 : -1;  } 

}

 

 

  1. 【推荐】集合初始化时,尽量指定集合初始值大小。 说明:ArrayList尽量使用

ArrayList(int initialCapacity) 初始化。 前提是能知道集合大致的大小说明:

List<StudentVO> list1 = new ArrayList<>();   

List<StudentVO> list2 = new ArrayList<>(1000000);   参考http://blog.csdn.net/java2000_net/article/details/5215882

 

  1. 【推荐】使用entrySet遍历Map类集合KV,而不是keySet方式进行遍历。 说明:keySet其实是遍历了2次,一次是转为Iterator对象,另一次是从hashMap中取出key所对应的value。而 entrySet只是遍历了一次就把key和value都放到了entry中,效率更高。如果是JDK8,使用foreach方法。 正例:values()返回的是V值集合,是一个list集合对象;keySet()返回的是K值集合,是一个Set集合对象;entrySet()返回的是K-V值组合集合。

 

  1. 【参考】利用Set元素唯一的特性,可以快速对一个集合进行去重操作,避免使用List的 contains方法进行遍历、对比、去重操作。

 

(六) 并发处理

  1. 【强制】获取单例对象需要保证线程安全,其中的方法也要保证线程安全。

说明:资源驱动类、工具类、单例工厂类都需要注意。 

建议在系统启动时单线程加载一些静态资源的情况下使用最为广泛。

 

  1. 【强制】线程资源必须通过线程池提供,不允许在应用中自行显式创建线程。线程池必须有最大线程数上限。

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

 

  1. 【强制】SimpleDateFormat 是线程不安全的类,一般不要定义为static变量,如果定义为 static,必须加锁,或者使用DateUtils工具类。 正例:注意线程安全,使用DateUtils。亦推荐如下处理:

private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() { 

@Override  protected DateFormat initialValue() {  return new SimpleDateFormat("yyyy-MM-dd");  } 

}; 

说明:如果是JDK8的应用,可以使用Instant代替Date,LocalDateTime代替Calendar, DateTimeFormatter代替Simpledateformatter,官方给出的解释:simple beautiful strong immutable thread-safe。

 参考http://www.cnblogs.com/zemliu/archive/2013/08/29/3290585.html

 

 

 

  1. 【强制】高并发时,同步调用应该去考量锁的性能损耗。能用无锁数据结构,就不要用锁;

能锁区块,就不要锁整个方法体;能用对象锁,就不要用类锁。 

 

  1. 【强制】对多个资源、数据库表、对象同时加锁时,需要保持一致的加锁顺序,否则可能会造成死锁。 说明:线程一需要对表A、B、C依次全部加锁后才可以进行更新操作,那么线程二的加锁顺序也必须是A、B、C,否则可能出现死锁。

 

  1. 【强制】并发修改同一记录时,避免更新丢失,要么在应用层加锁,要么在缓存加锁,要么在数据库层使用乐观锁,使用version作为更新依据。 说明:如果每次访问冲突概率小于

20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于3次。 

 

  1. 【推荐】使用CountDownLatch进行异步转同步操作,每个线程退出前必须调用countDown方法,线程执行代码注意catch异常,确保countDown方法可以执行,避免主线程无法执行至 countDown方法,直到超时才返回结果。 说明:注意,子线程抛出异常堆栈,不能在主线程

try-catch到。 

 

(七) 控制语句

  1. 【强制】在一个switch块内,每个case要么通过break/return等来终止,要么注释说明程序将继续执行到哪一个case为止;在一个switch块内,都必须包含一个default语句并且放在最后,即使它什么代码也没有。

 

  1. 【强制】在if/else/for/while/do语句中必须使用大括号,即使只有一行代码,避免使用下

面的形式:if (condition) statements; 

 

  1. 【推荐】推荐尽量少用else, if-else的方式可以改写成: if(condition){ 

... 

return obj; 

// 接着写else的业务逻辑代码; 

说明:如果非得使用if()...else if()...else...方式表达逻辑,【强制】请勿超过3层,超过请使用状态设计模式。 

正例:逻辑上超过3层的if-else代码可以使用卫语句,或者状态模式来实现。

 

  1. 【推荐】循环体中的语句要考量性能,以下操作尽量移至循环体外处理,如定义对象、变量、获取数据库连接,进行不必要的try-catch操作(这个try-catch是否可以移至循环体外)。

 

          Apple apple = null;

 

        for (int i = 0; i < 10000; i++) {              apple = new Apple();//正例

                  Apple appleError = new Apple();//反例

                            }

 

 

 

  1. 【强制】类、类属性、类方法的注释必须使用Javadoc规范,使用/**内容*/格式,不得使用

//xxx方式。 说明:在IDE编辑窗口中,Javadoc方式会提示相关注释,生成Javadoc可以正确输出相应注释;在IDE中,工程调用方法时,不进入方法即可悬浮提示方法、参数、返回值的意义,提高阅读效率。 

 

  1. 【强制】所有的抽象方法(包括接口中的方法)必须要用Javadoc注释、除了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能。 说明:对子类的实现要求,或者调用注意事项,请一并说明。

 

  1. 【强制】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释

使用/* */注释,注意与代码对齐。 

 

  1. 【强制】所有的枚举类型字段必须要有注释,说明每个数据项的用途。

 

  1. 【推荐】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑等的修改。

 

  1. 【参考】注释掉的代码尽量要配合说明,而不是简单的注释掉。 说明:代码被注释掉有两种可能性:
    • 后续会恢复此段代码逻辑。
    • 永久不用。前者如果没有备注信息,难以知晓注释动机。后者建议直接删掉(代码仓库保存了历史代码)。

 

(八) 其它

  1. 【强制】在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度。 说明:不要在方法体内定义:Pattern pattern = Pattern.compile(规则);

 

  1. 【强制】velocity调用POJO类的属性时,建议直接使用属性名取值即可,模板引擎会自动按规范调用POJO的getXxx(),如果是boolean基本数据类型变量(boolean命名不需要加is前缀),会自动调用isXxx()方法。 说明:注意如果是Boolean包装类对象,优先调用 getXxx()的方法。

 

  1. 【强制】后台输送给页面的变量必须加$!{var}——中间的感叹号。 说明:如果var=null或者不存在,那么${var}会直接显示在页面上。

 

  1. 【推荐】尽量不要在vm中加入变量声明、逻辑运算符,更不要在vm模板中加入任何复杂的逻辑。

 

 

 

二、日志&SQL

(一) 异常处理

 

  1. 【强制】异常不要用来做流程控制,条件控制,因为异常的处理效率比条件分支低。

 

  1. 【强制】对大段代码进行try-catch,这是不负责任的表现。catch时请分清稳定代码和非稳定代码,稳定代码指的是无论如何不会出错的代码。对于非稳定代码的catch尽可能进行区分异常类型,再做对应的异常处理。

 

  1. 【强制】捕获异常是为了处理它,不要捕获了却什么都不处理而抛弃之,如果不想处理它,请将该异常抛给它的调用者。最外层的业务使用者,必须处理异常,将其转化为用户可以理解的内容。

 

  1. 【强制】有try块放到了事务代码中,catch异常后,如果需要回滚事务,一定要注意手动回滚事务。

 

  1. 【强制】finally块必须对资源对象、流对象进行关闭,有异常也要做try-catch。

 

  1. 【强制】不能在finally块中使用return,finally块中的return返回后方法结束执行,不会再执行try块中的return语句。

 

  1. 【推荐】在代码中使用“抛异常”还是“返回错误码”,对于公司外的http/api开放接口必须使用“错误码”;而应用内部推荐异常抛出;跨应用间RPC调用优先考虑使用Result方式,封装 isSuccess、“错误码”、“错误简短信息”。 说明:关于RPC方法返回方式使用Result方式的理由: 1)使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。 2)如果不加栈信息,只是new自定义异常,加入自己的理解的error message,对于调用端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输的性能损耗也是问题。

 

  1. 【强制】异常信息应该包括两类信息:案发现场信息和异常堆栈信息。如果不处理,那么往上抛。 正例:error(各类参数或者对象toString + "_" + e.getMessage(), e);

 

  1. 【推荐】谨慎地记录日志。生产环境禁止输出debug日志;有选择地输出info日志;如果使用warn来记录刚上线时的业务行为信息,一定要注意日志输出量的问题,避免把服务器磁盘撑爆,并记得及时删除这些观察日志。 说明:大量地输出无效日志,不利于系统性能提升,也不利于快速定位错误点。记录日志时请思考:这些日志真的有人看吗?看到这条日志

你能做什么?能不能给问题排查带来好处? 

 

(二) SQL 规约

  1. 【强制】不要使用count(列名)或count(常量)来替代count(*),count(*)就是SQL92定义的标准统计行数的语法,跟数据库无关,跟NULL和非NULL无关。 说明:count(*)会统计值为 NULL的行,而count(列名)不会统计此列为NULL值的行。

 

  1. 【强制】当某一列的值全是NULL时,count(col)的返回结果为0,但sum(col)的返回结果为 NULL,因此使用sum()时需注意NPE问题。 正例:可以使用如下方式来避免sum的NPE问题:

SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;  

  1. 【强制】 在代码中写分页查询逻辑时,若count为0应直接返回,避免执行后面的分页语句。

 

  1. 【推荐】in操作能避免则避免,若实在避免不了,需要仔细评估in后边的集合元素数量,控制在1000个之内。

 

  1. 【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明。 说明:1)增加查询分析器解析成本。2)增减字段容易与resultMap配置不一致。

 

  1. 【强制】xml配置中参数注意使用:#{},#param# 不要使用${} 此种方式容易出现SQL注入。

 

  1. 【强制】iBATIS自带的queryForList(String statementName,int start,int size)不推荐使用。 说明:其实现方式是在数据库取到statementName对应的SQL语句的所有记录,再通过subList取start,size的子集合,线上因为这个原因曾经出现过OOM。 正例:在xml中引入 #start#, #size# 

Map<String, Object> map = new HashMap<String, Object>();  map.put("start", start);  map.put("size", size);  

  1. 【参考】@Transactional事务不要滥用。事务会影响数据库的QPS,另外使用事务的地方需要考虑各方面的回滚方案,包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

 

 

 

 

总结:此内容大部分都是来自于阿里2017年2月的java开发规范。请大家引起重视。没有规矩不成方圆。

posted @ 2024-02-07 17:12  CharyGao  阅读(35)  评论(0)    收藏  举报