java编码规范_java编码规范考试 - CSDN
精华内容
参与话题
  • Java编码规范总结(腾讯+阿里)

    万次阅读 2019-05-06 20:28:03
    Java编码规范总结(参考腾讯编码规范) 一、java文件组织 文件组织规则:由于超过2000行的程序难以阅读,应该尽量避免出现超过2000行的程序。一个Java源文件都包含一个单一的公共类或接口。若私有类和接口与一个...

    以下内容转自他人,总结,感谢他人的分享!!!

    Java编码规范总结(参考腾讯编码规范)

    一、java文件组织

    文件组织规则:由于超过2000行的程序难以阅读,应该尽量避免出现超过2000行的程序。一个Java源文件都包含一个单一的公共类或接口。若私有类和接口与一个公共类相关联,可以将它们和公共类放入同一个源文件。公共类必须是这个文件中的第一个类或接口。

    文件组织顺序

    1.文件注释:所有的源文件都应该在开头有一个注释,其中列出文件的版权声明、文件名、功能描述以及创建、修改记录:

     

    2.包和引入语句:在多数Java源文件中,第一个非注释行是包语句。在它之后可以跟导包语句

    3. 类或接口注释:采用JavaDoc文档注释,在类、接口定义之前应当对其进行注释,包括类、接口的描述、最新修改者、版本号、参考链接等;

     

    注:JavaDoc文档注释:描述Java的类、接口、构造方法、方法、以及字段。每个文档注释都会被置于注释定界符/**...*/之中,一个注释对应一个类、接口或成员。该注释应位于声明之前。文档注释的第一行(/**)不需缩进,随后的文档注释每行都缩进1格(使星号纵向对齐)。

    4. 类或接口的声明

    5. 类或接口的实现注释:如果有关类或接口的信息不适合作为“类或接口文档注释”,可以在类或接口的实现注释中给出;

    6. 类的(静态)变量:首先是类的公共变量,随后是保护变量,再后是包一级别的变量(没有访问修饰符),最后是私有变量;

    7. 实例变量:首先是公共级别的,随后是保护级别的,再后是包一级别的(没有访问修饰符),最后是私有级别的;

    8. 构造方法;

    9. 普通方法:方法应该按功能分组,而不应该按作用域或访问权限进行分组。

    二、代码风格

          1.缩进:程序块要采用缩进风格编写,缩进只使用TAB键,不能使用空格键(编辑器中请将TAB设置为4格);方法体的开始、类的定义、以及if、for、do、while、switch、case语句中的代码都要采用缩进方式;

          2.对齐:程序块的分界符左大括号"{" 和右大括号"}"都另起一行,应各独占一行并且位于同一列,同时与引用它们的语句左对齐;对齐只使用TAB键,不使用空格键;不允许把多个短语句写在一行中,即一行只写一条语句;if、for、do、while、case、switch、default等语句自占一行。

          3.换行:一行的长度超过80个字符需要换行,换行规则如下:

    在一个逗号后面断开;

    在一个操作符前面断开;

    长表达式要在低优先级操作符处划分新行;

    新行缩进2个TAB。

    4.间隔:类、方法及相对独立的程序块之间、变量说明之后必须加空行;关键字之后要留空格, 象if、for、while  等关键字之后应留一个空格再跟左括号"(", 以突出关键字;方法名与其左括号"("之间不要留空格, 以与关键字区别;二元操作符如   " ="、" +="  " >="、" <="、" +"、" *"、" %"、" &&"、" ||"、" <<" ," ^" 等的前后应当加空格;一元操作符如" !"、" ~"、" ++"、" --"等前后不加空格;xiang"[ ]"、" ." 这类操作符前后不加空格;for语句中的表达式应该被空格分开;强制转型后应该跟一个空格。

    三、注释

    1.原则:对已经不推荐使用的类和方法需要注明@Deprecated,并说明替代的类或者方法;对于针对集合、开关的方法,要在方法注释中表明是否多线程安全。

    2.字段注释: 采用JavaDoc文档注释,定义为public的字段必需给出注释,在类的(静态)变量、实例变量定义之前当对其进行注释,给出该字段的描述等:

     

    3.方法注释:采用JavaDoc文档注释,在方法定义之前当对其进行注释,包括方法的描述、输入、输出及返回值说明、抛出异常说明、参考链接等:

     

    4.单行注释格式//

    6.多行注释格式/*……*/

    三、命名规则

    1.基本规则:使用可以准确说明变量、字段、类、接口、包等完整的英文描述符;采用大小写混合,提高名字的可读性;采用该领域的术语;尽量少用缩写,但如果一定要使用,当使用公共缩写和习惯缩写等;避免使用相似或者仅在大小写上有区别的名字。

    2.包命名:包名一律小写, 少用缩写和长名;采用以下规则:

                                      [基本包].[项目名].[模块名].[子模块名]...

    不得将类直接定义在基本包下,所有项目中的类、接口等都应当定义在各自的项目和模块包中。

    3.类或接口命名:类或接口名是个一名词,采用大小写混合的方式,每个单词的首字母大写。尽量使你的类名简洁而富于描述。使用完整单词,避免用缩写词(除非该缩写词被更广泛使用,像URL,HTML)。

    4.变量命名: 采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;变量名不应以下划线或美元符号开头;尽量避免单个字符的变量名,除非是一次性的临时变量。临时变量通常被取名为i,j,k,m和n,它们一般用于整型;c,d,e,它们一般用于字符型;不采用匈牙利命名法则,对不易清楚识别出该变量类型的变量应使用类型名或类型名缩写作其后缀;组件或部件变量使用其类型名或类型名缩写作其后缀;集合类型变量,例如数组和矢量,应采用复数命名或使用表示该集合的名词做后缀。

    5.常量命名:全部采用大写,单词间用下划线隔开。

    6.方法命名:方法名是一个动词,采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;取值类可使用get前缀,设值类可使用set前缀,判断类可使用is(has)前缀。

    四、声明

    1.类或接口的声名:类、接口定义语法规范如下

    [可见性][('abstract'|'final')] [Class|Interface] class_name

    [('extends'|'implements')][父类或接口名]{

    //方法体

    }

    2.方法声明:良好的程序设计应该尽可能减小类与类之间耦合,所遵循的经验法则是:尽量限制成员函数的可见性。如果成员函数没必要公有 (public),就定义为保护 (protected);没必要保护 (protected),就定义为私有 (private);方法定义语法规范:

    [可见性]['abstract'] [‘static’] ['final'] ['synchronized'][返回值类型] method_name(参数列表)[('throws')][异常列表]{

    //方法体

    }

    声明顺序:构造方法、静态公共方法、静态私有方法、公共方法、友元方法、受保护方法、私有方法、main方法;方法参数建议顺序:(被操作者,操作内容,操作标志,其他)。

    3.变量声明:一行一个声明;声明局部变量的同时初始化(在变量的初始值依赖于某些先前发生的计算的特殊情况下可以不用同时初始化);只在代码块的开始处声明变量,(一个块是指任何被包含在大括号"{"和"}"中间的代码)不要在首次用到该变量时才声明;避免声明的局部变量覆盖上一级声明的变量,即不要在内部代码块中声明相同的变量名;公共和保护的可见性应当尽量避免,所有的字段都建议置为私有,由获取和设置成员函数(Getter、Setter)访问;定义一个变量或者常量的时候,不要包含包名(类似java.security.MessageDigest digest = null),除非是两个包有相同的类名;数组声明时应当将"[]"跟在类型后,而不是字段名后;声明顺序:常量、类变量、实例变量、公有字段、受保护字段、友元字段、私有字段。

    五、异常

          1.捕捉异常的目的是为了处理它

          2. 多个异常应分别捕捉并处理,避免使用一个单一的catch来处理。

    六、习惯

    1. if、for、do、while等语句的执行语句部分无论多少都要加括号"{}"

    2. 每当一个case顺着往下执行时(因为没有break语句),通常应在break语句的位置添加注释;

    3. 尽量避免在循环中构造和释放对象

    4. 在使用局部变量的过程,按就近原则处理。不允许定义一个局部变量,然后在很远的地方才使用;

    5.相同的功能不允许复制成N份代码;

    6. 在处理 String 的时候要尽量使用 StringBuffer 类。

    。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

    阿里开发规范终极版整理(精简)

    Java开发规范

    命名

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

    正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion

    反例: macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

     

    【规范】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase 风格,必须遵从驼峰形式。

    正例: localValue / getHttpMessage() / inputUserId

     

    【规范】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。

     

    【规范】抽象类命名使用 Abstract 或 Base 开头 ; 异常类命名使用 Exception 结尾 ; 测试类命名以它要测试的类的名称开始,以 Test 结尾。枚举类名建议带上 Enum 后缀,枚举成员名称需要全大写,单词间用下划线隔开。

     

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

     

    【规范】各层命名规约:

    A) Service / DAO 层方法命名规约

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

    2 ) 获取多个对象的方法用 list 做前缀(习惯:getXXXList)。

    3 ) 获取统计值的方法用 count 做前缀。

    4 ) 插入的方法用 save( 推荐 ) 或 insert 做前缀。

    5 ) 删除的方法用 remove( 推荐 ) 或 delete 做前缀。

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

    B) 领域模型命名规约

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

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

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

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

     

    常量

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

    反例: String key =" Id # taobao _"+ tradeId;

    cache . put(key , value);

     

    格式规约

    【风格】单行太长需换行

     

    【风格】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。

     

    OOP规约

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

     

    【规范】所有的覆写方法,必须加@ Override 注解。

     

    【规范】对外暴露的接口签名,原则上不允许修改方法签名,避免对接口调用方产生影响。接口过时必须加@Deprecated 注解,并清晰地说明采用的新接口或者新服务是什么

     

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

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

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

     

    【规范】所有的相同类型的包装类对象之间值的比较,全部使用 equals 方法比较。(注意空指针)

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

     

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

    1 ) 所有的 POJO 类属性必须使用包装数据类型。

    2 ) RPC 方法的返回值和参数必须使用包装数据类型。

    3 ) 所有的局部变量【推荐】使用基本数据类型。

     

    【强制】序列化类新增属性时,请不要修改 serialVersionUID 字段,避免反序列失败 ; 如果完全不兼容升级,避免反序列化混乱,那么请修改 serialVersionUID 值。

     

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

     

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

    说明:

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

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

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

    System.out.println(ary.length);

     

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

     

    【风格】类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter / setter方法。

     

    【效率】final 可提高程序响应效率,声明成 final 的情况:

    1 ) 不需要重新赋值的变量,包括类属性、局部变量。

    2 ) 对象参数前加 final ,表示不允许修改引用的指向。

    3 ) 类方法确定不允许被重写。

    4 )例子:final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);

     

    集合处理

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

    1) 只要重写 equals ,就必须重写 hashCode 。

    2) 因为 Set 存储的是不重复的对象,依据 hashCode 和 equals 进行判断,所以 Set 存储的对象必须重写这两个方法。

    3) 如果自定义对象做为 Map 的键,那么必须重写 hashCode 和 equals 。

     

    【强制】不要在 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”,会是同样的结果吗?(java.util.ConcurrentModificationException)

    正例:

    Iterator<String> it = a.iterator();

    while(it.hasNext()){

    String temp = it.next();

    if(删除元素的条件){

    it.remove();

    }

    }

     

    【规范】集合初始化时,尽量指定集合初始值大小。

    说明: ArrayList 尽量使用 ArrayList(int initialCapacity) 初始化。

     

    【规范】使用 entrySet 遍历 Map 类集合 KV,而不是 keySet 方式进行遍历。

    说明:keySet 其实是遍历了 2 次,一次是转为 Iterator 对象,另一次是从 hashMap 中取出 key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中,效 率更高。如果是 JDK8,使用 Map.foreach 方法

    Map<String, String> map = new HashMap<String, String>();

    map.put("1", "@@");

    map.put("2", "##");

     

    /**

    * JDK8推荐使用

    */

    map.forEach((K, V) -> {

    System.out.println("Key : " + K);

    System.out.println("Value : " + V);

    });

     

    /**

    * foreach推荐使用

    */

    for (Map.Entry<String, String> entry : map.entrySet()) {

    System.out.println("Key : " + entry.getKey());

    System.out.println("Value : " + entry.getValue());

    }

     

    /**

    * 不推荐使用

    */

    for (String key : map.keySet()) {

    System.out.println("Key : " + key);

    System.out.println("Value : " + map.get(key));

    }

     

    【强制】高度注意 Map 类集合 K/V 能不能存储 null 值的情况,如下表格:

    集合类

    Key

    Value

    Super

    说明

    Hashtable

    不允许为 null

    不允许为 null

    Dictionary

    线程安全

    ConcurrentHashMap

    不允许为 null

    不允许为 null

    AbstractMap

    分段锁技术

    TreeMap

    不允许为 null

    允许为 null

    AbstractMap

    线程不安全

    HashMap

    允许为 null

    允许为 null

    AbstractMap

    线程不安全

     

    并发处理

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

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

     

    【规范】创建线程或线程池时请指定有意义的线程名称,方便出错时回溯。

    正例:

    public class TimerTaskThread extends Thread { public TimerTaskThread(){

    super.setName("TimerTaskThread"); ... }

     

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

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

     

    【规范】线程池不允许使用 Executors 去创建,而是通过 ThreadPoolExecutor 的方式,这样 的处理方式让写的同学更加明确线程池的运行规则规避资源耗尽的风险。 说明:Executors 返回的线程池对象的弊端如下:

    1)FixedThreadPool 和 SingleThreadPool:

    允许的请求队列长度为 Integer.MAX_VALUE,可能会堆积大量的请求,从而导致 OOM。

    2)CachedThreadPool 和 ScheduledThreadPool:

    允许的创建线程数量为 Integer.MAX_VALUE,可能会创建大量的线程,从而导致 OOM。

     

    【效率】高并发时,同步调用应该去考量锁的性能损耗。能用无锁数据结构,就不要用锁;能 锁区块,就不要锁整个方法体;能用对象锁,就不要用类锁。

     

    【强制】对多个资源、数据库表、对象同时加锁时,需要保持一致的加锁顺序,否则可能会造 成死锁。

    说明:线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作,那么线程二的加锁顺序 也必须是 A、B、C,否则可能出现死锁。

     

    【规范】并发修改同一记录时,避免更新丢失,要么在应用层加锁,要么在缓存加锁,要么在 数据库层使用乐观锁,使用 version 作为更新依据。

    说明:如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次 数不得小于 3 次。

     

    【规范】多线程并行处理定时任务时,Timer 运行多个 TimeTask 时,只要其中之一没有捕获 抛出的异常,其它任务便会自动终止运行,使用ScheduledExecutorService 则没有这个问题。

     

    【规范】HashMap 在容量不够进行 resize 时由于高并发可能出现死链,导致 CPU 飙升,在 开发过程中注意规避此风险。

     

    控制语句

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

     

    【规范】在 if/else/for/while/do 语句中必须使用大括号,即使只有一行代码,避免使用 下面的形式:if (condition) statements;

     

    【规范】推荐尽量少用 else, if-else 的方式可以改写成:

    if(condition){

    ...

    return obj; }

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

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

    超过请使用状态设计模式 或者 卫语句

    卫语句示例:

    1. public void today() { if (isBusy()) {
    2. System.out.println(“change time.”); return;
    3. }
    4. if (isFree()) {
    5. System.out.println(“go to travel.”);
    6. return;
    7. }
    8. System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
    9. return;
    10. }


     

     

    【规范】除常用方法(如 getXxx/isXxx)等外,不要在条件判断中执行其它复杂的语句,将复 杂逻辑判断的结果赋值给一个有意义的布尔变量名,以提高可读性。

    说明:很多 if 语句内的逻辑相当复杂,阅读者需要分析条件表达式的最终结果,才能明确什么 样的条件执行什么样的语句,那么,如果阅读者分析逻辑表达式错误呢?

    正例:

    //伪代码如下

    boolean existed = (file.open(fileName, "w") != null) && (...) || (...); if (existed) {

    ... }

    反例:

    if ((file.open(fileName, "w") != null) && (...) || (...)) { ...

    }

     

    【规范】方法中需要进行参数校验的场景:

    1) 调用频次低的方法。

    2) 执行时间开销很大的方法,参数校验时间几乎可以忽略不计,但如果因为参数错误导致

    中间执行回退,或者错误,那得不偿失。

    3) 需要极高稳定性和可用性的方法。

    4) 对外提供的开放接口,不管是RPC/API/HTTP接口。

    5) 敏感权限入口。

     

    【规范】方法中不需要参数校验的场景:

    1) 极有可能被循环调用的方法,不建议对参数进行校验。但在方法说明里必须注明外部参

    数检查。

    2) 底层的方法调用频度都比较高,一般不校验。毕竟是像纯净水过滤的最后一道,参数错误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中,部署在同一 台服务器中,所以 DAO 的参数校验,可以省略。

    3) 被声明成private只会被自己代码所调用的方法,如果能够确定调用方法的代码传入参 数已经做过检查或者肯定不会有问题,此时可以不校验参数。

     

    注释规约

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

     

    【规范】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、 异常说明外,还必须指出该方法做什么事情,实现什么功能。

    说明:对子类的实现要求,或者调用注意事项,请一并说明。

     

    【风格】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释使用/* */注释,注意与代码对齐。

     

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

     

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

     

    【规范】注释掉的代码尽量要配合说明,而不是简单的注释掉。

    说明:代码被注释掉有两种可能性:

    1)后续会恢复此段代码逻辑。

    2)永久不用。前者如果没 有备注信息,难以知晓注释动机。

    后者建议直接删掉(代码仓库保存了历史代码)。

     

    【风格】特殊注释标记,请注明标记人与标记时间。注意及时处理这些标记,通过标记扫描, 经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

    1) 待办事宜(TODO):( 标记人,标记时间,[预计处理时间]) 表示需要实现,但目前还未实现的功能。这实际上是一个 Javadoc 的标签,目前的 Javadoc

    还没有实现,但已经被广泛使用。只能应用于类,接口和方法(因为它是一个 Javadoc 标签)。

    2) 错误,不能工作(FIXME):(标记人,标记时间,[预计处理时间])

    在注释中用 FIXME 标记某代码是错误的,而且不能工作,需要及时纠正的情况。

     

    异常

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

     

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

     

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

     

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

     

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

     

    【规范】方法的返回值可以为 null,不强制返回空集合,或者空对象等,必须添加注释充分 说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。

     

    【规范】防止 NPE,是程序员的基本修养,注意 NPE 产生的场景:

    1) 返回类型为包装数据类型,有可能是null,返回int值时注意判空。

    反例:public int f(){ return Integer 对象}; 如果为 null,自动解箱抛 NPE。

    2) 数据库的查询结果可能为null。

    3) 集合里的元素即使isNotEmpty,取出的数据元素也可能为null。

    4) 远程调用返回对象,一律要求进行NPE判断。

    5) 对于Session中获取的数据,建议NPE检查,避免空指针。

    6) 级联调用obj.getA().getB().getC();一连串调用,易产生NPE。

     

    【规范】在代码中使用“抛异常”还是“返回错误码”,对于公司外的 http/api 开放接口必须 使用“错误码”;而应用内部推荐异常抛出;跨应用间 RPC 调用优先考虑使用 Result 方式,封 装 isSuccess、“错误码”、“错误简短信息”。

    说明:关于 RPC 方法返回方式使用 Result 方式的理由:

    1)使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。

    2)如果不加栈信息,只是new自定义异常,加入自己的理解的error message,对于调用 端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输 的性能损耗也是问题。

     

    【规范】避免出现重复的代码(Don’t Repeat Yourself),即DRY原则。

     

    日志

    【规范】应用中不可直接使用日志系统(Log4j、Logback)中的 API,而应依赖使用日志框架

    SLF4J 中的 API,使用门面模式的日志框架,有利于维护和各个类的日志处理方式统一。

    import org.slf4j.Logger;

    import org.slf4j.LoggerFactory;

    private static final Logger logger = LoggerFactory.getLogger(Abc.class);

     

    【规范】日志文件推荐至少保存 15 天,因为有些异常具备以“周”为频次发生的特点。

     

    【规范】应用中的扩展日志(如打点、临时监控、访问日志等)命名方式: appName_logType_logName.log。

    logType:日志类型,推荐分类有 stats/desc/monitor/visit 等;

    logName:日志描述。这种命名的好处:通过文件名就可知 道日志文件属于什么应用,什么类型,什么目的,也有利于归类查找。

    正例:mppserver 应用中单独监控时区转换异常,如: mppserver_monitor_timeZoneConvert.log

    说明:推荐对日志进行分类,错误日志和业务日志尽量分开存放,便于开发人员查看,也便于 通过日志对系统进行及时监控。

     

    【规范】对 trace/debug/info 级别的日志输出,必须使用条件输出形式或者使用占位符的方式

    说明:logger.debug("Processing trade with id: " + id + " symbol: " + symbol); 如果日志级别是 warn,上述日志不会打印,但是会执行字符串拼接操作,如果 symbol 是对象, 会执行 toString()方法,浪费了系统资源,执行了上述操作,最终日志却没有打印。 正例:(条件)

    if (logger.isDebugEnabled()) {

    logger.debug("Processing trade with id: " + id + " symbol: " + symbol);

    }

    正例:(占位符)

    logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);

     

    * 避免重复打印日志,浪费磁盘空间,务必在 log4j.xml 中设置 additivity=false。

    正例:<logger name="com.taobao.dubbo.config" additivity="false">

     

    【规范】可以使用warn 日志级别来记录用户输入参数错误的情况,避免用户投诉时,无所适 从。注意日志输出的级别,error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必 要,请不要在此场景打出 error 级别。

     

    【规范】谨慎地记录日志。生产环境禁止输出 debug 日志;有选择地输出 info 日志;如果使 用 warn 来记录刚上线时的业务行为信息,一定要注意日志输出量的问题,避免把服务器磁盘 撑爆,并记得及时删除这些观察日志。

    说明:大量地输出无效日志,不利于系统性能提升,也不利于快速定位错误点。记录日志时请

     

    思考:这些日志真的有人看吗?看到这条日志你能做什么?能不能给问题排查带来好处?

     

    其它

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

     

    【规范】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();

    说明:如果想获取更加精确的纳秒级时间值,用 System.nanoTime()。在 JDK8 中,针对统计 时间等场景,推荐使用Instant 类。

     

    【规范】对于“明确停止使用的代码和配置”,如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去,避免造成过多垃圾。

     

    单元测试

    【强制】好的单元测试必须遵守 AIR 原则。

    说明:单元测试在线上运行时,感觉像空气(AIR)一样并不存在,但在测试质量的保障上,却是非常关键的。好的单元测试宏观上来说,具有自动化、独立性、可重复执行的特点。
     A:Automatic(自动化)
     I:Independent(独立性)

     R:Repeatable(可重复) 

    【强制】单元测试应该是全自动执行的,并且非交互式的。测试框架通常是定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测 试中不准使用 System.out 来进行人肉验证,必须使用 assert 来验证。


    【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护,单元测试用例之间 决不能互相调用,也不能依赖执行的先后次序。
    反例:method2 需要依赖 method1 的执行,将执行结果做为 method2 的输入。

     

    【强制】对于单元测试,要保证测试粒度足够小,有助于精确定位问题。单测粒度至多是类级别,一般是方法级别。 

    说明:只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的 交互逻辑,那是集成测试的领域。


    【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。 

    说明:新增代码及时补充单元测试,如果新增代码影响了原有单元测试,请及时修正。

     

    【推荐】单元测试的基本目标:语句覆盖率达到 70%;核心模块的语句覆盖率和分支覆盖率都 要达到 100%
    说明:在工程规约的应用分层中提到的 DAO 层,Manager 层,可重用度高的 Service,都应该 进行单元测试。

     

    【推荐】编写单元测试代码遵守 BCDE 原则,以保证被测试模块的交付质量。
    l B:Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。

    C:Correct,正确的输入,并得到预期的结果。

    l D:Design,与设计文档相结合,来编写单元测试
    l E:Error,强制错误信息输入(:非法数据、异常流程、非业务允许输入等),并得 到预期的结果。

     

    【推荐】和数据库相关的单元测试,可以设定自动回滚机制,不给数据库造成脏数据。或者 对单元测试产生的数据有明确的前后缀标识。
    正例:在 RDC 内部单元测试中,使用 RDC_UNIT_TEST_的前缀标识数据。


    【推荐】在设计评审阶段,开发人员需要和测试人员一起确定单元测试范围,单元测试最好 覆盖所有测试用例(UC)。


    【推荐】单元测试作为一种质量保障手段,不建议项目发布后补充单元测试用例,建议在项 目提测前完成单元测试。

     

    【参考】不要对单元测试存在如下误解:
    l 那是测试同学干的事情。本文是开发手册,凡是本文内容都是与开发同学强相关的。

    单元测试代码是多余的。汽车的整体功能与各单元部件的测试正常与否是强相关的。 l

    单元测试代码不需要维护。一年半载后,那么单元测试几乎处于废弃状态。
    l 单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。

     

    MySQL开发规范

    建表规约

    【规范】表达是与否概念的字段,必须使用 is_xxx 的方式命名,数据类型是 unsigned tinyint ( 1表示是,0表示否),此规则同样适用于odps建表。 说明:任何字段如果为非负数,必须是 unsigned。

     

    【规范】表名、字段名必须使用小写字母或数字;禁止出现数字开头,禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。

    正例:getter_admin,task_config,level3_name

    反例:GetterAdmin,taskConfig,level_3_name

     

    【规范】唯一索引名为 uk_字段名;普通索引名则为 idx_字段名。

     

    【规范】小数类型为 decimal,禁止使用 float 和 double。

    说明:float 和 double 在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不 正确的结果。如果存储的数据范围超过 decimal 的范围,建议将数据拆成整数和小数分开存储

     

    【规范】如果存储的字符串长度几乎相等,使用 char 定长字符串类型。

     

    【效率】varchar 是可变长字符串,不预先分配存储空间,长度不要超过 5000,如果存储长 度大于此值,定义字段类型为 text,独立出来一张表,用主键来对应,避免影响其它字段索 引效率。

     

    【规范】表的命名最好是加上“业务名称_表的作用”。

    正例:tiger_task / tiger_reader / mpp_config

     

    【规范】库名与应用名称尽量一致。

     

    【规范】如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。

     

    【效率】字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。冗余字段应遵循:

    1)不是频繁修改的字段。

    2)不是 varchar 超长字段,更不能是 text 字段。 正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存 储类目名称,避免关联查询。

     

    【效率】单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。 说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。

     

    【效率】合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检 索速度

    正例:人的年龄用 unsigned tinyint(表示范围 0-255,人的寿命不会超过 255 岁);海龟 就必须是 smallint,但如果是太阳的年龄,就必须是 int;如果是所有恒星的年龄都加起来, 那么就必须使用 bigint。

     

    索引规约

    【效率】业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引。

    说明:不要以为唯一索引影响了 insert 速度,这个速度损耗可以忽略,但提高查找速度是明 显的;另外,即使在应用层做了非常完善的校验和控制,只要没有唯一索引,根据墨菲定律, 必然有脏数据产生

     

    【规范】超过三个表禁止 join。需要 join 的字段,数据类型保持绝对一致;多表关联查询 时,保证被关联的字段需要有索引。

    说明:即使双表 join 也要注意表索引、SQL 性能。

     

    【规范】在 varchar 字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据 实际文本区分度决定索引长度。

    说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为 20 的索引,区分 度会高达 90%以上,可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度 来确定。

     

    【规范】页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决。

    说明:索引文件具有 B-Tree 的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索 引。

     

    【规范】如果有 order by 的场景,请注意利用索引的有序性。order by 最后的字段是组合 索引的一部分,并且放在索引组合顺序的最后,避免出现 file_sort 的情况,影响查询性能。

    正例:where a=? and b=? order by c; 索引:a_b_c

    反例:索引中有范围查找,那么索引有序性无法利用,如:WHERE a>10 ORDER BY b; 索引 a_b 无法排序。

     

    【效率】利用覆盖索引来进行查询操作,来避免回表操作。

    说明:如果一本书需要知道第 11 章是什么标题,会翻开第 11 章对应的那一页吗?目录浏览 一下就好,这个目录就是起到覆盖索引的作用。 正例:能够建立索引的种类:主键索引、唯一索引、普通索引,而覆盖索引是一种查询的一种 效果,用explain的结果,extra列会出现:using index。

     

    【效率】利用延迟关联或者子查询优化超多分页场景

    说明:MySQL 并不是跳过 offset 行,而是取 offset+N 行,然后返回放弃前 offset 行,返回 N 行,那当 offset 特别大的时候,效率就非常的低下,要么控制返回的总页数,要么对超过 特定阈值的页数进行 SQL 改写。

    正例:先快速定位需要获取的 id 段,然后再关联:(优化在可以少查表1的很多字段

    SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

     

    【效率】SQL 性能优化的目标:至少要达到 range 级别,要求是 ref 级别,如果可以是 consts 最好。

    说明:

    1)consts 单表中最多只有一个匹配行(主键或者唯一索引),在优化阶段即可读取到数据。

    2)ref 指的是使用普通的索引(normal index)。

    3)range 对索引进行范围检索。

    反例:explain 表的结果,type=index,索引物理文件全扫描,速度非常慢,这个 index 级 别比较 range 还低,与全表扫描是小巫见大巫。

     

    【规范】建组合索引的时候,区分度最高的在最左边

    正例:如果 where a=? and b=? ,a 列的几乎接近于唯一值,那么只需要单建 idx_a 索引即 可。

    说明:存在非等号和等号混合判断条件时,在建索引时,请把等号条件的列前置。如:where a>? and b=? 那么即使 a 的区分度更高,也必须把 b 放在索引的最前列

     

    【说明】创建索引时避免有如下极端误解:

    1)误认为一个查询就需要建一个索引。

    2)误认为索引会消耗空间、严重拖慢更新和新增速度。

    3)误认为唯一索引一律需要在应用层通过“先查后插”方式解决。

     

    SQL规约

    【规范】不要使用 count(列名)或 count(常量)来替代 count(*),count(*)就是 SQL92 定义 的标准统计行数的语法,跟数据库无关,跟 NULL 和非 NULL 无关。

    说明:count(*)会统计值为 NULL 的行,而 count(列名)不会统计此列为 NULL 值的行。

     

    【说明】count(distinct col) 计算该列除 NULL 之外的不重复数量。注意 count(distinct col1, col2) 如果其中一列全为NULL,那么即使另一列有不同的值,也返回为0。

     

    【说明】当某一列的值全是 NULL 时,count(col)的返回结果为 0,但 sum(col)的返回结果为 NULL,因此使用 sum()时需注意 NPE 问题。

    正例:可以使用如下方式来避免sum的NPE问题:SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

     

    【说明】使用 ISNULL()来判断是否为 NULL 值。注意:NULL 与任何值的直接比较都为 NULL。

    说明:

    1) NULL<>NULL的返回结果是NULL,而不是false。

    2) NULL=NULL的返回结果是NULL,而不是true。

    3) NULL<>1的返回结果是NULL,而不是true。

     

    【规范】不得使用外键与级联,一切外键概念必须在应用层解决

    说明:(概念解释)学生表中的 student_id 是主键,那么成绩表中的 student_id 则为外键。 如果更新学生表中的 student_id,同时触发成绩表中的 student_id 更新,则为级联更新。外键与级联更新适用于单机低并发,不适合分布式、高并发集群;级联更新是强阻塞,存在数 据库更新风暴的风险;外键影响数据库的插入速度。

     

    【规范】数据订正时,删除和修改记录时,要先 select,避免出现误删除,确认无误才能执行更新语句。

     

    【效率】in 操作能避免则避免,若实在避免不了,需要仔细评估 in 后边的集合元素数量,控制在 1000 个之内。(可以用用 EXISTS ,NOT EXISTS 或 JOIN代替)

     

    【规范】如果有全球化需要,所有的字符存储与表示,均以 utf-8 编码,那么字符计数方法 注意:

    说明:

    SELECT LENGTH("轻松工作"); 返回为12

    SELECT CHARACTER_LENGTH("轻松工作"); 返回为4 如果要使用表情,那么使用 utfmb4 来进行存储,注意它与 utf-8 编码的区别。

     

    【规范】TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但 TRUNCATE无事务且不触发 trigger,有可能造成事故,故不建议在开发代码中使用此语句

    说明:TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

     

    ORM规约

    【规范】POJO 类的 boolean 属性不能加 is,而数据库字段必须加 is_,要求在 resultMap 中 进行字段与属性之间的映射。

    说明:参见定义 POJO 类以及数据库字段定义规定,在 sql.xml 增加映射,是必须的。

     

    【安全】配置XML文件时注意SQL注入问题。

     

    【规范】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

     

    【强制】更新数据表记录时,必须同时更新记录对应的 gmt_modified 字段值为当前时间。

     

    【规范】不要写一个大而全的数据更新接口,传入为 POJO 类,不管是不是自己的目标更新字 段,都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL 时,尽量不要更新无改动的字段,一是易出错;二是效率低;三是 binlog 增加存储。

     

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

     

    工程规约


     

     

    【说明】图中默认上层依赖于下层,箭头关系表示可直接依赖,如:开放接口层可以依赖于Web 层,也可以直接依赖于 Service 层,依此类推。

     开放接口层:可直接封装 Service接口暴露成 RPC 接口;通过 Web 封装成 http 接口;网关控 制层等

     终端显示层:各个端的模板渲染并执行显示层。当前主要是 velocity 渲染,JS 渲染,JSP 渲 染,移动端展示层等。

     Web 层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。(Controller)

     Service 层:相对具体的业务逻辑服务层。

     Manager 层:通用业务处理层,它有如下特征:

    1) 对第三方平台封装的层,预处理返回结果及转化异常信息;

    2) 对Service层通用能力的下沉,如缓存方案、中间件通用处理;

    3) 与DAO层交互,对DAO的业务通用能力的封装。

     DAO 层:数据访问层,与底层 MySQL、Oracle、Hbase 进行数据交互。

     外部接口或第三方平台:包括其它部门 RPC 开放接口,基础平台,其它公司的 HTTP 接口。

     

    【规范】(分层异常处理规约)在 DAO 层,产生的异常类型有很多,无法用细粒度的异常进 catch,使用catch(Exception e)方式,并throw new DAOException(e),不需要打印日志,因为日志在 Manager/Service 层一定需要捕获并打到日志文件中去,如果同台服务器 再打日志,浪费性能和存储。在 Service 层出现异常时,必须记录出错日志到磁盘,尽可能带 上参数信息,相当于保护案发现场。如果 Manager 层与 Service 同机部署,日志方式与 DAO 层处理一致,如果是单独部署,则采用与 Service 一致的处理方式。Web 层绝不应该继续往上抛异常,因为已经处于顶层,如果意识到这个异常将导致页面无法正常渲染,那么就应该直接跳转到友好错误页面,加上用户容易理解的错误提示信息。开放接口层要将异常处理成错误码 和错误信息方式返回。

     

    【规范】分层领域模型规约:

     DO(Data Object):与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。(Entity)

     DTO(Data Transfer Object):数据传输对象,Service 和 Manager 向外传输的对象。

     BO(Business Object):业务对象。可以由 Service 层输出的封装业务逻辑的对象。

     QUERY:数据查询对象,各层接收上层的查询请求。注:超过 2 个参数的查询封装,禁止 使用 Map 类来传输。

     VO(View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象。

     

    服务器规约

    【效率】高并发服务器建议调小 TCP 协议的 time_wait 超时时间。

    说明:操作系统默认 240 秒后,才会关闭处于 time_wait 状态的连接,在高并发访问下,服务器端会因为处于 time_wait 的连接数太多,可能无法建立新的连接,所以需要在服务器上 调小此等待值。

    正例:在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值(秒):

    net.ipv4.tcp_fin_timeout = 30

     

    【效率】调大服务器所支持的最大文件句柄数(File Descriptor,简写为fd)。

    说明:主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理,即一个连接对 应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024,当并发连接数很大时很 容易因为 fd 不足而出现“open too many files”错误,导致新的连接无法建立。 建议将 linux 服务器所支持的最大句柄数调高数倍(与服务器的内存数量相关)。

     

    【规范】给 JVM 设置-XX:+HeapDumpOnOutOfMemoryError 参数,让 JVM 碰到 OOM 场景时输出 dump 信息。

    说明:OOM 的发生是有概率的,甚至有规律地相隔数月才出现一例,出现时的现场信息对查错 非常有价值。

     

    【规范】服务器内部重定向使用 forward;外部重定向地址使用 URL 拼装工具类来生成,否则 会带来 URL 维护不一致的问题和潜在的安全风险。

     

    安全规约

    【安全】隶属于用户个人的页面或者功能必须进行权限控制校验。

    说明:防止没有做水平权限校验就可随意访问、操作别人的数据,比如查看、修改别人的订单。

     

    【安全】用户敏感数据禁止直接展示,必须对展示数据脱敏。

    说明:查看个人手机号码会显示成:158****9119,隐藏中间 4 位,防止隐私泄露。

     

    【安全】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定,防止 SQL 注入, 禁止字符串拼接 SQL 访问数据库。

     

    【安全】用户请求传入的任何参数必须做有效性验证。

    说明:忽略参数校验可能导致:

    l page size 过大导致内存溢出

    l 恶意 order by 导致数据库慢查询

    l 任意重定向

    l SQL 注入

    l 反序列化注入

    l 正则输入源串拒绝服务 ReDoS

    说明:Java 代码用正则来验证客户端的输入,有些正则写法验证普通用户输入没有问题, 但是如果攻击人员使用的是特殊构造的字符串来验证,有可能导致死循环的效果

     

    【安全】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。

     

    【安全】表单、AJAX 提交必须执行 CSRF 安全过滤。

    说明:CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在 CSRF 漏洞的应用/网站,攻击者可以事先构造好 URL,只要受害者用户一访问,后台便在用户 不知情情况下对数据库中用户参数进行相应修改。

     

    【安全】在使用平台资源,譬如短信、邮件、电话、下单、支付,必须实现正确的防重放限制, 如数量限制、疲劳度控制、验证码校验,避免被滥刷、资损。

    说明:如注册时发送验证码到手机,如果没有限制次数和频率,那么可以利用此功能骚扰到其 它用户,并造成短信平台资源浪费。

     

    【安全】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过 滤等风控策略。

     

    展开全文
  • java编码规范,非常详细 每个switch-case语句都有最后一个default以确保处理了全集。switch中,每一条case分支必须使用break语句结束
  • Java编码规范

    千次阅读 多人点赞 2014-03-14 10:25:30
    先借编码规范之名,行吐槽之实,抱歉。 写干净整洁的代码 阅读代码,眼缘很重要。代码是程序员的脸,保持干净整洁。 记得格式化代码。 建议使用eclipse默认的就行,Ctrl+Shift+F。项目内部格式化风格一定要统一,...

    先借编码规范之名,行吐槽之实,抱歉。

    写干净整洁的代码

    阅读代码,眼缘很重要。代码是程序员的脸,保持干净整洁。

    1. 记得格式化代码
      建议使用eclipse默认的就行,Ctrl+Shift+F。项目内部格式化风格一定要统一,否则svn很难track。鉴于Java开发库以及流行的开源框架都用Block起始大括号不换行风格,Google也如此规范,统一为这种风格。
    2. 去除没有用到的类引用
      纯粹是美观的考量。Google要求import语句里面不允许出现*,更不能引入没有用到的代码。Eclipse里面的快捷键是Ctrl+Shift+O,这个键还能帮忙导入用到的类。
    3. 删掉无用的老代码
      修改代码的时候,有些同学会把老的没有用的代码注释起来,像宝贝一样生怕弄丢,日积月累,注释的代码比有用的代码还多几倍,很难阅读和维护。请删掉它,备份的问题放心的交给SVN或Git。
    4. 删掉IDE帮忙自动生成的无用注释
      TODO Auto-generated method stud等等之流的,请删掉,不解释。
    5. 合理利用空行
      空行的唯一作用是分割逻辑代码,是阅读时候大脑的一个休息区。但是空行又是昂贵的,编辑器一页代码200行以内,使用空行太过奢侈的话,我就光阅读空行了。Google不鼓励多个空行,依我的观点,绝对不能有两个相联的空行,原因简单,浪费可耻,眼睛跳跃也累。当然也反对几十行代码没有一个空行,大脑得累死。总之,优美的代码一定合理的利用了空行,空行都用不好写不出优美的代码。
    6. 想办法把Warning干掉吧
      每一个Warning背后都有一个故事,泛型,未被使用的Class引用,未被使用的private方法,未被使用的field,class cast,序列化等等。搞懂一个Warning背后的故事,优雅的解决掉一个Warning,你就向高手迈进了一步。如果实在是搞不定,注释SuppressWarning能够暴力的帮助你。

    高效运用注释

    有人说注释和代码一样重要,我不太认同。简单优雅的代码比注释更直接易懂,注释会骗人,代码不会,注释不正确比没有注释糟糕很多很多,一大堆无用的注释浪费空间,浪费脑力,不如没有注释。一段关键的算法,一个场景的特殊处理,用简短的注释解释思路,这里注释对于后来的维护人员来说,比代码更加重要。接口的注释是使用接口人员的说明文档,对他们来说也比代码重要。如果一段代码需要你很多很多的注释才能解释清楚,那么请重写那段代码,直到简短注释甚至无需注释。

    1. 给别人调用的接口要注释清楚
      包括Interface、非Java Bean的public方法以及工具类里面的public static方法。关注做什么(不是怎么做),输入输出,特殊情况处理(比如null或不合法参数),异常情况。这种为块级(Block)注释,一般用/** comments */格式。
    2. 特殊的算法简洁清楚地注释
      特殊的算法体现的是作者当时解决问题的思路和算法,具有业务上或者算法上的特殊性,需要备注一下,以防忘记或者其他维护同事难以理解。通常用单行注释即可,特别长的用/* comments */ 格式。
    3. 具有特殊控制意义或者业务意义的变量简洁注释
      主要是帮助阅读代码的时候帮助理解。格式和第二条相同。
    4. 千万别在代码的各个角落留下您的大名或者Ticket单号
      关于名字,请在Class的注释里面加一个@author yourname。阅读代码的时候,只有遇到很烂或者很优雅的代码,我才会去关注作者是谁,通过Class里面的@Author和SVN抑或Git,很轻松的就知道代码出自谁的手。关注代码的时候实在是没有兴趣思考你是谁。至于Ticket单号,提交代码的时候注释就足够了,项目由代码构成,而非Ticket,需要追踪的时候SVN或Git都能够轻松地帮忙搞定。
    5. 块级元素里面慎用多行注释
      可以理解为方法内部慎用多行注释。方法内部应该Focus在代码的实现上,而不是实现的思路,思路请移到方法的注释里面。方法里面的注释应该关注在一些特殊情况处理,程序逻辑的跳转上面,一般单行注释足够胜任。如果方法内部要用大段的注释,还是那句话,请重写。

    命名简洁一致

    命名规范是代码规范的重要一环。总的原则是遵循惯例,简洁,团队甚至个人命名保持一致。

    1. 除了方法用动词,其它的都用名词命名
      项目名,包名,类名,变量名,参数名都用名词命名,方法用动词开始命名。
    2. 按照Java的惯例命名
      包名全小写,每一个文件夹用一个名词命名,注意有且一个词,且长度尽量短一些。类名标准的HelloWorld格式,有人问FBIHelloWorld好呢还是FbiHelloWorld好,我看着后者顺眼,你呢?普通变量,方法名,参数名一律helloWorld,hWorld可不可以?反射的时候有问题,也不好看,建议每一个单词至少两个字母。Final变量HELLO_WORLD,同样不解释。
    3. 简洁即美
      特别强调,简洁不是说鼓励简写,相反简写要慎用,最好团队内部达成共识。我说的简洁是指找那么一个贴切、简短的词或词组来命名。
    4. 命名规范在团队内部保持一致
      A君FBIHelloWorld,B君FbiHelloWorld,C君hWorld,甚至A君混合两种风格,整个项目会显得混乱,难以理解和维护。

    理解Java几个基本的概念

    一些Java的基本概念一定要吃透,否则很容易犯低级错误。

    Exception

    麻烦统计一下你们项目里面处理异常,简单地e.printStackTrace()个数,少不能说明你们项目代码质量一定很高,但太多了一定意味着你们的代码质量不咋地,如果这些烂代码由很多人提交,那更是悲剧。e.printStackTrace()只是把Exception toString(),然后输出到System.err,开发的时候控制台还能显示一下,生产环境到哪里去找。我觉得简单e.printStackTrace()和try catch之后什么都不干一样恶劣。想看报错信息?借助Log4j或者Logback记日志吧,既能开发的时候控制台看到,也能在生产时记录到文件系统。

    • 何时抛出异常
      不正常的场景出现,当前程序决定罢工,并可选择地携带一些错误信息告知调用者,小心,异常。如果你的程序就是最后一环,拜托,别抛了,选择更优雅的方式吧。
    • 何时处理异常
      确定你可以处理那样的异常,并且决定catch之后如何继续下面的操作。catch之后记录日志是标配。如果你开发GUI,你就是最后的消费者,必须处理异常。

    Transaction

    如果你开发的系统要求数据的完整性和准确性,请花些时间好好吃透Transaction。有一个业务Service A,分为两个子Service A1, A2。如果分别调用A1和A2,并放到两个Transaction里面,如果A1执行成功,A2失败并Rollback,请问发生了什么?Service的粒度划分和Transaction的使用非常的重要。

    Thread

    不懂或者半懂不懂千万别用多线程,要用就去好好的了解一下它。依我的理解,多线程仅用在两个地方,性能提升和响应式(Responsive)的GUI界面。

    Access

    两个字,要明确。类,构造函数,属性,方法的访问权限要明确。public, protected,package,private,四个级别,了解不难,用好要功力。有的不喜欢明确定义访问级别的朋友会辩解说,我看JDK里面有的属性或者方法就没有申明权限嘛,JDK的开发工程师也懒。哈哈,往后看看,大多会特别的注释说是package级别的,如果package关键字能够用来定义package权限,他们估计早用了,何必还多写那么些冗余的注释。interface里面不用明确申明public,因为默认就是public的,而且只能是public的。程序员太懒惰不好,太勤快了也不好,难当。

    寻求更好的解决办法(Better Solution)

    项目经理A或业务达人B跑过来,某客户有一个新的需求,请帮忙如此如此改一下系统,如此如此设计。假如你听话马上开始勤奋地敲代码,我觉得90%以上该方案都不是什么好方案。can work与work fine之间有着遥远的距离,改BUG,支持新需求绝对不仅仅是If Else那么简单。套用Linus大神的话,如果A君或者B君比你更了解你的系统,帮你设计由你实现,那么你就没有价值,实现的系统一定很烂,不如A君或者B君直接来实现。大神的徒弟不一定就是大神,传输大都有损耗。找出所谓需求背后的真正动机,结合当前的系统寻求更好的解决方案。何谓更好,各有各的看法,个人觉得,要保持架构风格的统一,要考虑未来类似需求的普适性,要简单准确有效。

    结语

    以上List处于开放状态,欢迎批评,欢迎加内容。一家之言,还请多包涵。

    展开全文
  • 编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范编码规范
  • java编码规范

    千次阅读 2017-11-01 15:21:30
     本文档以SUN的标准Java代码规范为基础,结合公司的实际需要,做一些修改和补充,编写次文档的目的是规范安信捷开发代码,增加代码清晰度,减少bug,降低后期维护成本和代码审查,养成代码规范的习惯,便于开发人员...

    1章 引言

    1.1介绍

        本文档SUN的标准Java代码规范为基础,结合公司的实际需要做一些修改和补充,编写次文档的目的是规范公司开发代码,增加代码清晰度,减少bug,降低后期维护成本和代码审查,养成代码规范的习惯,便于开发人员自身成长。

     


    第2章  标识符命名

    注:所有标识符不能出现中文,尽量使用通俗英文,不可拼音和英文混用。


    2.1 包名

    全部使用小写字母单词间不要用字符隔开

    正例:com.axj.batchfile

    反例:com.axj.batch_file


    2.2 类名


    2.2.1 类命名

    类名使用驼峰命名,每个自然语义的单词首字母大写,其他字母小写

    正例:SendThread

    反例:sendThreadSendthread


    2.2.2 类后缀

    类名不同的后缀代表不同的类型:

    后缀名

    意义

    举例

     Exception

    这个类是异常类

    Axj Exception

    Service

    表明这个类是个服务类,里面包含了给其他类提同业务服务的方法

    AccountService

    Impl

    这个类是一个实现类,AccountServiceImpl实现AccountService

    AccountServiceImpl

    Test

    日常测试类,以测试名称开头,Test为后缀

    CodeTest

    Enum

    这个类是枚举类,枚举成员名称需要全大写,单词间用下划线隔开

    TimeEnum

    Inter

    这个类是一个接口

    LifeCycleInter

    Dao

    这个类封装了数据访问方法,一般为接口

    PaymentOrderDao

    Action

    直接处理页面请求,管理页面逻辑了类

    UpdateOrderListAction

    Listener

    响应某种事件的类

    PaymentSuccessListener

    Event

    这个类代表了某种事件

    PaymentSuccessEvent

    Servlet

    一个Servlet

    PaymentCallbackServlet

    Factory

    生成某种对象工厂的类

    PaymentOrderFactory

    Adapter

    用来连接某种以前不被支持的对象的类

    DatabaseLogAdapter

    Job

    某种按时间运行的任务

    PaymentOrderCancelJob

    Wrapper

    这是一个包装类,为了给某个类提供没有的能力

    SelectableOrderListWrapper

    Bean

    这是一个POJO

    MenuStateBean

    Thread

    表示是线程类

    SendThread

    POJO

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

     

    Abstract

    抽象类最好能用“Abstract”做为类命名的开头(前缀)

    AbstractBeanFactory


    2.3方法名

    首字母小写,后面自然语义的单词首字母都大写

    正例:closeSession

    反例:CloseSessionclosesession

    动词在前,名词在后

    正例:closeSession

    反例:sessionClose

    方法命名格式(方法名要准确表达业务的含义):

    前缀名

    意义

    举例

    create

    创建

    createOrder()

    delete

    删除

    deleteOrder()

    add

    创建,暗示新创建的对象属于某个集合

    addPaidOrder()

    remove

    删除

    removeOrder()

    init或则initialize

    初始化,暗示会做些诸如获取资源等特殊动作

    initializeObjectPool

    destroy

    销毁,暗示会做些诸如释放资源的特殊动作

    destroyObjectPool

    open

    打开

    openConnection()

    close

    关闭

    closeConnection()<

    read

    读取

    readUserName()

    write

    写入

    writeUserName()

    get

    获得

    getName()

    set

    设置

    setName()

    prepare

    准备

    prepareOrderList()

    copy

    复制

    copyCustomerList()

    modity

    修改

    modifyActualTotalAmount()

    calculate

    数值计算

    calculateCommission()

    do

    执行某个过程或流程

    doOrderCancelJob()

    dispatch

    判断程序流程转向

    dispatchUserRequest()

    start

    开始

    startOrderProcessing()

    stop

    结束

    stopOrderProcessing()

    send

    发送某个消息或事件

    sendOrderPaidMessage()

    receive

    接受消息或时间

    receiveOrderPaidMessgae()

    respond

    响应用户动作

    responseOrderListItemClicked()

    find

    查找对象

    findNewSupplier()

    update

    更新对象

    updateCommission()


    2.4 变量、参数名

    变量一定要清楚表达什么意思,一般取一些通俗有意义的名字,尽量使用简短英文单词。

    命名规则:

    1、首字母小写,后面自然语义的单词首字母都大写

    2、只能以字母、“_”“$”符号作为变量名开头。

    3、变量中可包含数字,但不能以数字开头。

    4、除了“_”“$”符号以外,变量中不能包含其他特殊字符。

    5、不能用classintStringpublicjava关键字做为变量名。

    6、在java中变量名严格区分大小写,例如:nameName就是两个不同的变量

    7、静态变量和枚举类型字母全大写,多个单词之间用”_”分隔,如:TIME_EVENT



    第3章 代码注释


    3.1 注释分类

    注:注释主要分为2种,实现注释和文档注释。


    3.1.1 实现注释

    实现注释使用/*...*///界定,使用/*...*/来进行块注释使用//进行行注释位于注释代码上一行


    3.1.2文档注释

    文档注释描述Java的类、接口、构造器,方法,以及字段(field)。每个文档注释都会被置于注释定界符/**...*/之中,一个注释对应一个类、接口或成员。该注释应位于声明之前javadocj2sdk里面一个非常重要的工具,如果你按照规范在Java的源代码里面写好注释的话,那么它就可以生成相应的文档便于开发者察看Myeclipse生成步骤,点击菜单栏的Project,选择generate javadoc下一步即可。

    javadoc参数定义:

    @author   对类的说明 标明开发该类模块的作者

    @version   对类的说明 标明该类模块的版本

    @see     对类、属性、方法的说明 参考转向,也就是相关主题

    @param    对方法的说明 对方法中某参数的说明

    @return   对方法的说明 对方法返回值的说明

    @exception  对方法的说明 对方法可能抛出的异常进行说明


    3.2 注释条件(必加)

    1、类的注释

    2、方法的注释

    3、在代码复杂处注释

    4、代码修改处注释上时间和修改原因

    5、全局变量注释

    6、在多重嵌套和循环逻辑上注释

    7、接口注释

    8、调用工具类中方法的注释


    3.3 注释举例


    3.3.1 类注释

    /**

     *类功能概述×××××××

     *

     *@author huwei

     *@time 2017-8-20

     */

    public class LogicManager {

    ......

    }


    3.3.2 方法注释

    /**

     * 方法说明×××××××

     *

      * @param1 参数说明

     * @param2 参数说明

      * @return 返回值说明

      * @throws Exception

      */

    public boolean executeLogic(int param1, int param2)throws Exception{

    ......

    return true;

    }


    3.3.3 全局变量、字段、属性注释

    public class ReadManager {

       /** 全局的计数变量*/

       private final int count;

       /** 字段/属性*/

       private String name;

    }


    3.3.4 代码域注释

                /*----------开始:解析数据库数据 ------- */

                //\1拆分数据库数据

                String Row[] = sStr.split("\1");

    waitRecord = new WaitRecord[Row.length];

     

                /* 循环存储对象到List */

    for (int i = 0; i < Row.length; i++) {

    String Col[] = Row[i].split("\2");

    waitRecord[i] = new WaitRecord();

    waitRecord[i].waitId = Col[0];

    waitRecord[i].userId = Col[1];

    waitRecord[i].username = Col[2];

    waitRecord[i].longId = Col[3];

                    waitList.add(waitRecord[i]);

    }

                  /*----------结束:解析数据库数据 ------- */



    第4章  编程实践


    4.1 空行

    空行一般用于分割特定区域代码,表达一段代码,总结为以下几种情况必须换行:

    1、代码注释前得换行

     

    2、两个方法之间换行

     


    3、不同逻辑段之间

     

     

    4、方法里的局部变量和第一条非局部变量代码之间

     

    4.2 换行

    1、一行代码最大不超过120字符,超过则换行

    2、大括号左右,总结如下:

    1左大括号前不换行

    2左大括号后换行

    3右大括号前换行

    4右大括号后面是else或逗号,则不换行否则作为终止符必须换行

    3+号等操作符前换行,逗号后面换行,增加代码可读性

     

    4.3 缩进

    缩进建议采用4个空格作为一个单位,可设置一个tab键为4个空格,一般为开始一个新的块使用缩进,块结束时返回先前的缩进级别(从属关系)。

    4.4 空格

    1、运算符之间使用空格

    正列:a == b ? true : false

    反例:a==b?true:false;

    2、逗号后使用空格,不能在逗号前

    正列:findData(a, b, c);

    反例:finData(a,b ,c);


    第五章 代码习惯

    5.1 异常抛出

    进程和线程可能出现一系列异常,异常的出现如果没有抛出可能会导致进程死掉或线程崩溃,所以需养成异常捕获抛出的习惯,避免应用因进程卡住,异常异常捕获后,需打印异常日志,否则出现异常时不好查找问题。

    5.2 减少嵌套

    代码嵌套层太多,会严重影响代码可读性,处理方法:

    1、使用return跳出,减少else使用

    2、条件使用逻辑运算符(&& ||等)进行拼接

    3、整合成子方法

    5.3 判断字符串相等

    1java中字符串的比较是==比较引用,equals 比较值

    我们经常习惯性的写上if(str1==str2),这种写法在java中可能会带来问题

     例子1String a="abc";String b="abc"

    那么a==b将返回true。因为在java中字符串的值是不可改变的,相同的字符串在内存中只会存

     一份,所以ab指向的是同一个对象;

    例子2String a=new String("abc"); String b=new String("abc");

     那么a==b将返回false,此时ab指向不同的对象。

     2equals方法比较的是字符串的内容是否相同

    exampleString a=new String("abc"); String b=new String("abc"); a.equals(b);将返回true

    通常情况下,为了避免出现上述问题,判断字符串是否相等使用equals方法,具体的原因得引出常量池概念,这里不做详细描述

    5.4 字符串拼接

    拼接字符串尽量使用StringBuffer或者StringBuilder使用+号每次会new一个对象,对空间和性能还是有一定影响的。

    5.5 NPE处理

    java开发最常见的异常就是NPEjava.lang.NullPointerException)异常,需有效的规避异常,进行null判断,可能出现null模块,取集合元素,数据截取,方法返回,socket传输的数据,数据库取值等等...

    5.6 日志输出

    平时调试代码或输出日志习惯使用System.out.println()system.out都写入到一个文件里去了,对一个文件的读写就会排队写而且syso在当前线程,必须写完才继续下面的程序。 如果使用log工具你的日志会发散在多个日志文件上。可以控制日志是否输出而且log工具只是通知要写日志,而不必等日志写完

     

    展开全文
  • Java基础——java代码规范详细版

    千次阅读 2019-07-03 11:41:57
    Java代码规范以SUN的标准Java代码规范为基础,为适应我们公司的实际需要,可能会做一些修改。本文档中没有说明的地方,请参看SUN Java标准代码规范。如果两边有冲突,以SUN Java标准为准。 1. 标识符命名规范 ...

    Java代码规范以SUN的标准Java代码规范为基础,为适应我们公司的实际需要,可能会做一些修改。本文档中没有说明的地方,请参看SUN Java标准代码规范。如果两边有冲突,以SUN Java标准为准。

    1. 标识符命名规范

    1.1 概述

    标识符的命名力求做到统一、达意和简洁。

    1.1.1 统一

    统一是指,对于同一个概念,在程序中用同一种表示方法,比如对于供应商,既可以用supplier,也可以用provider,但是我们只能选定一个使用,至少在一个Java项目中保持统一。统一是作为重要的,如果对同一概念有不同的表示方法,会使代码混乱难以理解。即使不能取得好的名称,但是只要统一,阅读起来也不会太困难,因为阅读者只要理解一次。

    1.1.2 达意

    达意是指,标识符能准确的表达出它所代表的意义,比如: newSupplier, OrderPaymentGatewayService等;而 supplier1, service2idtts等则不是好的命名方式。准确有两成含义,一是正确,二是丰富。如果给一个代表供应商的变量起名是 order,显然没有正确表达。同样的,supplier1, 远没有targetSupplier意义丰富。

    1.1.3 简洁

    简洁是指,在统一和达意的前提下,用尽量少的标识符。如果不能达意,宁愿不要简洁。比如:theOrderNameOfTheTargetSupplierWhichIsTransfered 太长, transferedTargetSupplierOrderName则较好,但是transTgtSplOrdNm就不好了。省略元音的缩写方式不要使用,我们的英语往往还没有好到看得懂奇怪的缩写。

    1.1.4 骆驼法则

    Java中,除了包名,静态常量等特殊情况,大部分情况下标识符使用骆驼法则,即单词之间不使用特殊符号分割,而是通过首字母大写来分割。比如: supplierName, addNewContract,而不是 supplier_name, add_new_contract

    1.1.5 英文 vs 拼音

    尽量使用通俗易懂的英文单词,如果不会可以向队友求助,实在不行则使用汉语拼音,避免拼音与英文混用。比如表示归档,用archive比较好, pigeonhole则不好,用guiDang尚可接受。

    1.2 包名

    使用小写字母如 com.xxx.settlment,不要 com.xxx.Settlement
    单词间不要用字符隔开,比如 com.xxx.settlment.jsfutil,而不要com.xxx.settlement.jsf_util

    1.3 类名

    1.3.1 首字母大写

    类名要首字母大写,比如 SupplierService, PaymentOrderAction;不要 supplierService, paymentOrderAction.

    1.3.2 后缀

    类名往往用不同的后缀表达额外的意思,如下表:

    后缀名

    意义

    举例

    Service

    表明这个类是个服务类,里面包含了给其他类提同业务服务的方法

    PaymentOrderService

    Impl

    这个类是一个实现类,而不是接口

    PaymentOrderServiceImpl

    Inter

    这个类是一个接口

    LifeCycleInter

    Dao

    这个类封装了数据访问方法

    PaymentOrderDao

    Action

    直接处理页面请求,管理页面逻辑了类

    UpdateOrderListAction

    Listener

    响应某种事件的类

    PaymentSuccessListener

    Event

    这个类代表了某种事件

    PaymentSuccessEvent

    Servlet

    一个Servlet

    PaymentCallbackServlet

    Factory

    生成某种对象工厂的类

    PaymentOrderFactory

    Adapter

    用来连接某种以前不被支持的对象的类

    DatabaseLogAdapter

    Job

    某种按时间运行的任务

    PaymentOrderCancelJob

    Wrapper

    这是一个包装类,为了给某个类提供没有的能力

    SelectableOrderListWrapper

    Bean

    这是一个POJO

    MenuStateBean

    1.4 方法名

    首字母小写,如 addOrder() 不要 AddOrder()
    动词在前,如 addOrder(),不要orderAdd()
    动词前缀往往表达特定的含义,如下表:

    前缀名

    意义

    举例

    create

    创建

    createOrder()

    delete

    删除

    deleteOrder()

    add

    创建,暗示新创建的对象属于某个集合

    addPaidOrder()

    remove

    删除

    removeOrder()

    init或则initialize

    初始化,暗示会做些诸如获取资源等特殊动作

    initializeObjectPool

    destroy

    销毁,暗示会做些诸如释放资源的特殊动作

    destroyObjectPool

    open

    打开

    openConnection()

    close

    关闭

    closeConnection()<

    read

    读取

    readUserName()

    write

    写入

    writeUserName()

    get

    获得

    getName()

    set

    设置

    setName()

    prepare

    准备

    prepareOrderList()

    copy

    复制

    copyCustomerList()

    modity

    修改

    modifyActualTotalAmount()

    calculate

    数值计算

    calculateCommission()

    do

    执行某个过程或流程

    doOrderCancelJob()

    dispatch

    判断程序流程转向

    dispatchUserRequest()

    start

    开始

    startOrderProcessing()

    stop

    结束

    stopOrderProcessing()

    send

    发送某个消息或事件

    sendOrderPaidMessage()

    receive

    接受消息或时间

    receiveOrderPaidMessgae()

    respond

    响应用户动作

    responseOrderListItemClicked()

    find

    查找对象

    findNewSupplier()

    update

    更新对象

    updateCommission()

    find方法在业务层尽量表达业务含义,比如 findUnsettledOrders(),查询未结算订单,而不要findOrdersByStatus() 数据访问层,find,update等方法可以表达要执行的sql,比如findByStatusAndSupplierIdOrderByName(Status.PAID, 345)

    1.5 域(field)名

    1.5.1 静态常量

    全大写用下划线分割,如

    public static find String ORDER_PAID_EVENT = “ORDER_PAID_EVENT”;

    1.5.2 枚举

    全大写,用下划线分割,如

    public enum Events {
    ORDER_PAID,
    ORDER_CREATED

    }

    1.5.3 其他

    首字母小写,骆驼法则,如:

    public String orderName;

    1.6 局部变量名

    参数和局部变量名首字母小写,骆驼法则。尽量不要和域冲突,尽量表达这个变量在方法中的意义。

    2. 代码格式

    用空格字符缩进源代码,不要用tab,每个缩进4个空格。

    2.1 源文件编码

    源文件使用utf-8编码,结尾用unix n 分格。

    2.2 行宽

    行宽度不要超过80Eclipse标准

    2.3 包的导入

    删除不用的导入,尽量不要使用整个包的导入。在eclipse下经常使用快捷键 ctrl+shift+o 修正导入。

    2.4 类格式

    2.5 域格式

    每行只能声明一个域。
    域的声明用空行隔开。

    2.5 方法格式

    2.6 代码块格式

    2.6.1 缩进风格

    大括号的开始在代码块开始的行尾,闭合在和代码块同一缩进的行首,例如:

    package com.test;

    public class TestStyle extends SomeClass implements AppleInter, BananaInter {

        public static final String THIS_IS_CONST = "CONST VALUE";

        private static void main(String[] args) {

            int localVariable = 0;

        }

        public void compute(String arg) {

            if (arg.length() >  0) {

                System.out.println(arg);

            }

     

            for (int i = 0; i < 10; i++) {

                  System.out.println(arg);

            }

           while (condition) {

           }

          do {

              otherMethod();

          } while (condition);

     

      switch (i) {

      case 0:

         callFunction();

         break;

      case 1:

         callFunctionb();

         break;

      default:

         break;

      }

     }

    }

    2.6.2 空格的使用

    2.6.2.1 表示分割时用一个空格

    不能这样:

    if       (               a >        b   )            {

        //do something here

    };

    2.6.2.2 二元三元运算符两边用一个空格隔开

    如下:

    a + b = c;

    b - d = e;

    return a == b ? 1 : 0;

    不能如下:

    a+b=c;

    b-d=e;

    return a==b?1:0;

    2.6.2.3 逗号语句后如不换行,紧跟一个空格

    如下:

    call(a, b, c);

    不能如下:

    call(a,b,c);

    2.6.3 空行的使用

    空行可以表达代码在语义上的分割,注释的作用范围,等等。将类似操作,或一组操作放在一起不用空行隔开,而用空行隔开不同组的代码, 如下:

    order = orderDao.findOrderById(id);

     

    //update properties

    order.setUserName(userName);

    order.setPrice(456);

    order.setStatus(PAID);

    orderService.updateTotalAmount(order);

    session.saveOrUpdate(order);

    上例中的空行,使注释的作用域很明显.

    • 连续两行的空行代表更大的语义分割。
    • 方法之间用空行分割
    • 域之间用空行分割
    • 超过十行的代码如果还不用空行分割,就会增加阅读困难

    3. 注释规范

    3.1 注释 vs 代码

    • 注释宜少而精,不宜多而滥,更不能误导
    • 命名达意,结构清晰, 类和方法等责任明确,往往不需要,或者只需要很少注释,就可以让人读懂;相反,代码混乱,再多的注释都不能弥补。所以,应当先在代码本身下功夫。
    • 不能正确表达代码意义的注释,只会损害代码的可读性。
    • 过于详细的注释,对显而易见的代码添加的注释,罗嗦的注释,还不如不写。
    • 注释要和代码同步,过多的注释会成为开发的负担
    • 注释不是用来管理代码版本的,如果有代码不要了,直接删除,svn会有记录的,不要注释掉,否则以后没人知道那段注释掉的代码该不该删除。

    3.2 Java Doc

    表明类、域和方法等的意义和用法等的注释,要以javadoc的方式来写。Java Doc是给类的使用者来看的,主要介绍 是什么,怎么用等信息。凡是类的使用者需要知道,都要用Java Doc 来写。非Java Doc的注释,往往是个代码的维护者看的,着重告述读者为什么这样写,如何修改,注意什么问题等。 如下:

    /**

    * This is a class comment

    */

    public class TestClass {

        /**

        * This is a field comment

        */

        public String name;

        /**

        * This is a method comment

        */

        public void call() {

        }

    }

    3.3 块级别注释

    3.3.1 块级别注释,单行时用 //, 多行时用 /* .. */

    3.3.2 较短的代码块用空行表示注释作用域

    3.3.3 较长的代码块要用

    /*------ start: ------*/

    /*-------- end: -------*/

    包围
    如:

    /*----------start: 订单处理 ------- */

    //取得dao

    OrderDao dao = Factory.getDao("OrderDao");

    /* 查询订单 */

    Order order = dao.findById(456);

    //更新订单

    order.setUserName("uu");

    order.setPassword("pass");

    order.setPrice("ddd");

    orderDao.save(order);

    /*----------end: 订单处理 ------- */

    3.3.4 可以考虑使用大括号来表示注释范围

    使用大括号表示注释作用范围的例子:

    /*----------订单处理 ------- */

    {

     //取得dao

     OrderDao dao = Factory.getDao("OrderDao");

     /* 查询订单 */

     Order order = dao.findById(456);

     

     //更新订单

     order.setUserName("uu");

     order.setPassword("pass");

     order.setPrice("ddd");

     

     orderDao.save(order);

    }

    3.4 行内注释

    行内注释用 // 写在行尾

    4 最佳实践和禁忌

    4.1 每次保存的时候,都让你的代码是最美的

    程序员都是懒惰的,不要想着等我完成了功能,再来优化代码的格式和结构,等真的把功能完成,很少有人会再愿意回头调整代码。

    4.2 使用log而不是System.out.println()

    log可以设定级别,可以控制输出到哪里,容易区分是在代码的什么地方打印的,而System.out.print则不行。而且,System.out.print的速度很慢。所以,除非是有意的,否则,都要用log。至少在提交到svn之前把System.out.print换成log

    4.3 每个if while for等语句,都不要省略大括号{}

    看下面的代码:

    if (a > b)

        a++;

    如果在以后维护的时候,需要在a > b 时,把b++,一步小心就会写成:

    if (a > b)

        a++;

        b++;

    这样就错了,因为无论ab是什么关系,b++都会执行。 如果一开始就这样写:

    if (a > b)  {

        a++;

    }

    相信没有哪个笨蛋会把b++添加错的。而且,这个大括号使作用范围更明显,尤其是后面那行很长要折行时。

    4.4 善用TODO:

    在代码中加入 //TODO: ,大部分的ide都会帮你提示,让你知道你还有什么事没有做。比如:

    if (order.isPaid()) {

        //TODO: 更新订单

    }

    4.5 在需要留空的地方放一个空语句或注释,告述读者,你是故意的

    比如:

    if (!exists(order)) {

        ;

    }

    或:

    if (!exists(order)) {

        //nothing to do

    }

    4.6 不要再对boolean值做true false判断

    比如:

    if (order.isPaid() == true) {

        // Do something here

    }

    不如写成:

    if (order.isPaid()) {

        //Do something here

    }

    后者读起来就很是 if order is paid, …. 要比 if order’s isPaid method returns true, … 更容易理解

    4.7 减少代码嵌套层次

    代码嵌套层次达3层以上时,一般人理解起来都会困难。下面的代码是一个简单的例子:

    public void demo(int a, int b, int c) {

        if (a > b) {

            if (b > c) {

                doJobA();

            } else if (b < c) {

                doJobB()

            }

        } else {

            if (b > c) {

                if (a < c) {

                    doJobC();

                }

            }

        }

    }

    减少嵌套的方法有很多:

    • 合并条件
    • 利用 return 以省略后面的else
    • 利用子方法

    比如上例,合并条件后成为:

    public void demo(int a, int b, int c) {

        if (a > b && b > c) {

            doJobA();

        }

        if (a > b && c > b) {

            doJobB();

        }

        if (a <= b && c < b && a < c) {

            doJobC();

        }

    }

    如果利用return 则成为:

    public void demo(int a, int b, int c) {

        if (a > b) {

            if (b > c) {

                doJobA();

                return;

            }

            doJobB()

            return;

        }

     

        if (b > c) {

            if (a < c) {

                doJobC();

            }

        }

    }

    利用子方法,就是将嵌套的程序提取出来放到另外的方法里。

    4.8 程序职责单一

    关注点分离是软件开发的真理。人类自所以能够完成复杂的工作,就是因为人类能够将工作分解到较小级别的任务上,在做每个任务时关注更少的东西。让程序单元的职责单一,可以使你在编写这段程序时关注更少的东西,从而降低难度,减少出错。

    4.9 变量的声明,初始化和被使用尽量放到一起

    比方说如下代码:

    int orderNum= getOrderNum();

    //do something withou orderNum here

    call(orderNum);

    上例中的注释处代表了一段和orderNum不相关的代码。orderNum的声明和初始化离被使用的地方相隔了很多行的代码,这样做不好,不如这样:

    //do something withou orderNum here

    int orderNum= getOrderNum();

    call(orderNum);

    4.10 缩小变量的作用域

    能用局部变量的,不要使用实例变量,能用实例变量的,不要使用类变量。变量的生存期越短,以为着它被误用的机会越小,同一时刻程序员要关注的变量的状态越少。实例变量和类变量默认都不是线程安全的,局部变量是线程安全的。比如如下代码:

    public class OrderPayAction{

        private Order order;

     

        public void doAction() {

            order = orderDao.findOrder();

            doJob1();

            doJob2();

        }

     

        private void doJob1() {

            doSomething(order);

        }

     

        private void doJob2() {

            doOtherThing(order);

        }

    }

    上例中order只不过担当了在方法间传递参数之用,用下面的方法更好:

    public class OrderPayAction{

        public void doAction() {

            order = orderDao.findOrder();

            doJob1(order);

            doJob2(order);

        }

     

        private void doJob1(Order order) {

            doSomething(order);

        }

     

        private void doJob2(Order order) {

            doOtherThing(order);

        }

    }

    4.11 尽量不要用参数来带回方法运算结果

    比如:

    public void calculate(Order order) {

        int result = 0;

        //do lots of computing and store it in the result

        order.setResult(result);

    }

     

    public void action() {

        order = orderDao.findOrder();

        calculate(order);

        // do lots of things about order

    }

    例子中calculate方法通过传入的order对象来存储结果, 不如如下写:

    public int calculate(Order order) {

        int result = 0;

        //do lots of computing and store it in the result

        return result;

    }

    public void action() {

        order = orderDao.findOrder();

        order.setResult(calculate(order));

        // do lots of things about order

    }

    4.12    除非有相当充足的理由,否则不许使用省略泛型类的类型参数

    养成良好的编码规范,从我做起

    展开全文
  • 标准的Java编码规范手册

    万次阅读 多人点赞 2016-05-10 17:23:23
    今天分享一个标准的Java编码规范给大家,希望对于大家今后的开发工作带来帮助。编码规范的意义  在项目开发维护中,编码规范作为开发规范的一个组成部分,是十分重要和必须的,它不仅仅是为了提高开发效率,也有利...
  • 阿里巴巴编码规范Java)满分答卷

    千次阅读 2019-02-28 17:50:43
    多选 1.如何处理单元测试产生的数据,下列哪些说法是正确的?...关于并发处理,下列哪些说法符合《阿里巴巴Java开发手册》:ABC A .线程资源必须通过线程池提供,不允许在应用中自行显式创建线程。...
  • idea配置阿里代码规范

    万次阅读 2019-04-16 11:19:47
    阿里近万名Java技术精英的经验总结,铸就了高含金量的《阿里巴巴Java开发手册》,并向业界开放,希望使团队在Java开发上更高效、容错、有协作性,提高代码质量并降低维护成本。本认证是对你的编码风格是否符合该手册...
  • IDEA 之 阿里JAVA规范插件

    万次阅读 2019-01-11 00:05:42
    gt;Settings-&gt;Plugins,如下图 2.查找alibaba插件并安装重启IDEA ...3.安装完成后,就可以开始体验...如果你的代码不符合阿里巴巴java规范的话,会有如下的扫描信息,可以据此信息改善我们的代码 以上提示...
  • CERT关于Java安全编码规范的新书

    千次阅读 2013-09-20 23:30:20
    CERT关于Java安全编码规范的新书:Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programshttp://...
  • Java中getBytes()的用法

    万次阅读 2013-09-10 17:27:32
    /** * * 1、Unicode是一种编码规范,是为... 2、java内部采用Unicode编码规范,也就是支持多语言的,具体采用的UTF-16编码方式。 3、不管程序过程中用到了gbk,iso8859-1等格式,在存储与传递的过程中实际
  • 2017年10月14日杭州云栖大会,Java代码规约扫描插件全球首发仪式正式启动,规范正式以插件形式公开走向业界,引领Java语言的规范之路。目前,插件已在云效公有云产品中集成,立即体验!(云效&gt;公有云&gt;...
  • 阿里巴巴Java开发手册,目前为 华山版,官方github地址
  • 获得阿里巴巴编码规范技能认证

    万次阅读 2019-12-11 16:19:49
    通过对阿里巴巴Java开发手册的学习与总结,今天进行了阿里巴巴举办的在线认证考试,并最终通过认证。 【认证过程】 1、学习资料: (1)在线---阿里巴巴Java开发手册终极版v1.3.0.pdf ...
  • IDEA安装阿里Java代码规范插件

    万次阅读 2018-04-13 17:39:10
    阿里java代码规范IDEA插件之傻瓜教程前言碎语千呼万唤始出来,阿里巴巴在首次发布java开发手册后,时隔一年终于推出了IDEA的代码检查插件了。插件应该是十月八号就悄悄的发布了,插件源码推迟了5天才上传。如果说...
  • 知识贵在积累。byte[]转String,编码与乱码问题,以及Base64编码相关学习。
  • 一、java文件组织 文件组织规则:由于超过2000行的程序难以阅读,应该尽量避免出现超过2000行的程序。一个Java源文件都包含一个单一的公共类或接口。若私有类和接口与一个公共类相关联,可以将它们和公共类放入同一...
  • 阿里巴巴编码规范Java) 题库

    千次阅读 2020-02-26 14:02:22
    关于索引效率,下列哪些说法符合《阿里巴巴java开发手册》 利用索引进行排序,下列哪些说法是正确的 关于组合索引,下列哪些说法符合《阿里巴巴java开发手册》 对于索引的基本原理,下列哪些说法是正确的 我把阿里的...
  • 由于我们 Andorid 也是使用 Java 来开发的,所以在大部分命名风格上也是遵从 Java 的命名规范,Java 统一规范标准有助于提高行业编码规范水平,提高我们的开发质量和效率,大大降低代码维护成本,今年年初阿里就发布...
1 2 3 4 5 ... 20
收藏数 159,373
精华内容 63,749
关键字:

java编码规范