程序编写规范

排版

    原则 团队应遵守一致的排版风格

    规则1 在不同的概念之间，增加空行。如import与包名，import与类名，方法与方法，类与类，变量声明与变量声明。

    规则2 将逻辑紧密相关的代码放在一起。

    规则3 控制一行的宽度，不要超过120个字符。换行应在低优先级运算符处换行。

    规则4 控制一行的宽度，在不同的概念之间（关键字、变量·、操作符等·）增加空格，以便区分概念。

    规则5 控制采用缩进来区分不同层次的概念（不用tab，用4空格）。

    建议1 将局部变量的作用域最小化。

    建议2 if,for,do,while,case,switch,default等语句自占一行，且if,for,do,while语句的执行语句无论多少都要加括号。

    建议3 控制好文件长度，最好不要超过500行。

注释

    原则 尽量使用代码来解释自己

    规则1 注释应解释代码的意图，而不是描述代码怎么做的。

    规则2 保证注释与代码一致，避免产生误导。

    规则3 注释应与其描述代码位置相邻，放在所注释代码上方或者右方，并与代码采用同样的缩进。

    建议1 不要用注释保留废弃代码。

    建议2 不要用注释记录修改日志。

命名

    原则 团队为包、类、方法、变量取一个好名字，使代码易于理解

    规则1 禁止使用魔鬼数字。

    规则2 常量命名，由全大写单词组成，单词间用下划线分割，且使用static final修饰

    规则3 变量、属性命名，使用名词，并采用首字母小写的驼峰命名

    规则4 方法的命名，用动词和动宾结构，采用首字母小写的驼峰命名

    规则5 类和接口的命名，采用首字母大写的驼峰命名法

    规则6 包的命名，由一个或若干个单词组成，所有的字母均为小写

变量和类型

    原则 谨慎使用静态成员变量

    错误使用静态变量可能有以下场景：

    1、认为静态变量属于某个实例，而实际是多个实例操作同一个变量，造成值与预期不一致

    2、没有注意静态变量的初始化顺序，读取还未初始化的静态变量值。

    推荐在以下场景中，合理使用静态变量：

    1、类的所有实例必须共享同一个变量时，比如计数器。

    2、工具类提供的常量，如配置文件中的参数“映射”到类的变量，基本第一次赋值后，数据不再被修改。

    3、单例模式中应用

    规则1 避免随意进行类型强行转换，应改善设计，或在转换前用instanceof进行判断。

    规则2 需要精确计算时不要使用float和double，建议使用int,long,BigDecimal。

    规则3 不能使用浮点数作为循环变量，例，精度问题会导致（float） 20000000000 == 20000000020为true

    规则4 浮点型数据判断相等不能直接使用 ==

            一般采用如下：

                        float a=...;

                        float b=...;

                        if(Math.abs(a-b)<1E-6f)

                        {

                         }

     规则5 避免同一个局部变量在前后表达不同的含义

     规则6 不要在单个的表达式中对相同的变量赋值吵过一次。

方法

    原则1 方法设计的第一原则是短小

    原则2 方法设计应遵循单一职责原则（SRP），一个方法仅完成一个功能

    原则3 方法设计应遵循单一抽象层次原则（SLAP）

    原则4 方法设计应遵循命名与查询职责分离原则（CQRS）

    规则1 不要把方法的入参作为工作变量/临时变量，除非特别需要（如，方法外需要改变后的方法内引用变量）

    规则2 使用类名调用静态方法，而不要用实例或表达式来调用

    建议1 应明确规定对接口方法参数的合法性由调用者负责还是由方法本身负责。

    建议2 谨慎使用可变数量参数的方法

    建议3 对接方法的参数不宜过多

包、类和接口

    原则1 类和接口的设计应遵循面向对象SOLID设计原则

                1、单一职责原则

                说明：就一个类而言，应该仅有一个引起它变化的原因。如果能想到多于一个的动机去改变类，那么这个类就具有多于一个的职责

异常

    原则1 只针对真正异常的情况才会使用exception机制

    规则2 对可恢复的情况使用受检异常（checked exception）对编程错误使用运行时异常（runtime exceptio） 

    规则3 不要忽略异常

    规则4 方法注释和文档中要包含所抛出异常的说明

    规则5 方法抛出的异常，应该与本身的抽象层次相对应

    规则6 在finally块中不要使用return、break或continue使finally块非正常结束。

    规则7 不要直接捕获受检异常的基类Exception

    建议1 对第三方API抛出的大量各类异常进行封装

    建议2 一个方法不应该抛出太多类型的异常