没有合适的资源?快使用搜索试试~ 我知道了~
一、命名规范 1.【强制】 严禁在代码中的命名使用拼音缩写 反例: BaoDan[保单]/ getBaoDanInfo()[获取保单信息] 二、格式规范 1.【强制】 使用同一的代码格式模板,基于IDE自动的格式化 三、注释规范 1.【推荐】 基本的注释要求 1) 注释需要准确的反映设计思想及代码逻辑 2)公共的方法或抽象类的方法,尽可能描述清楚:输入、输出、错误处理和返回码、以及可能抛出的异常。 3) 能够描述出业务的具体含义,使得读者能够快速了解代码背后的信息。 四、方法设计 1.【推荐】 方法的长度限制方法尽量不要超过100行,需要注意的是方法长度超过8000个字节码时,将不会被JIT编译成二进制码。 五、类设计 1.【推荐】 类成员与方法的可见性最小化任何类、方法、参数、变量,严控访问范围。过于宽泛的访问范围,不利于模块解耦。思考:如果是一个private的方法,想删除就删除,可是一个public的service方法,或者一个public的成员变量,删除一下。例外:为了单元测试,有时也可能将访问范围扩大,此时需要加上JavaDoc说明
资源推荐
资源详情
资源评论
编码规约
一、命名规范
1.【强制】 严禁在代码中的命名使用拼音缩写
反例: BaoDan[保单]/ getBaoDanInfo()[获取保单信息]
2.【强制】 禁止使用用非标准的英文缩写
反例: AbstractClass 缩写成 AbsClass/ condition 缩写成 condi。
3.【推荐】 包名全部小写。点分隔符之间尽量只有一个英语单词,即使有多个单词也不
使用下划线或大小写分隔
正例: com.xxx.launcher
反例: com.xxx.user_info,com.xxx.UserInfo
4.【强制】 方法名、参数、成员名、局部变量都同一使用驼峰形式。
正例: getUserInfo() / localValue / userName
5.【强制】 类名与接口名使用 UpperCamelCase 风格,遵从驼峰形式,对应 DTO/VO 等可
例外
正例: UserId / UserService / UserVO
反例: UserID / XMLService / UserVo
6.【强制】 常量命名全大写,单词间用下划线隔开。力求语义表达完整清楚,不要嫌名
字长。
正例: MAX_STOCK_COUNT
反例: MAX_COUNT
例外:对于 static final 字段不是一个真正的常量,比如不是基本类型时,不需要使用大
写。
正例: MAX_STOCK_COUNT
反例: MAX_COUNT
例外: 枚举常量类推荐全大写
7.【推荐】 如果使用到了通用的设计模式,在类名中体现,有利于阅读者快速理解设计
思想。
正例:OrderFactory、LoginProxy、ResourceObserver
8.【推荐】 枚举类名以 Enum 结尾; 抽象类使用 Abstract 或 Base 开头;异常类使用
Exception 结尾;测试类以它要测试的类名开始,以 Test 结尾
正例:DealStatusEnum, AbstractView,BaseView, TimeoutException,
UserServiceTest
9.【推荐】 实现类尽量用 Impl 的后缀与接口关联
正例:CacheService 的实现类可以命名为 CacheServiceImpl
10.【强制】 POJO 类中布尔类型的变量名,不要加 is 前缀,否则部分框架解析会引起序
列化错误
反例:Boolean isSuccess 的成员变量,它的 GET 方法也是 isSuccess(),部分框架在反射
解析的时候,“以为”对应的成员变量名称是 success,导致出错。
二、格式规范
1.【强制】 使用同一的代码格式模板,基于 IDE 自动的格式化
1) IDE 的默认代码格式模板,能简化绝大部分关于格式规范(如空格,括号)的描述。
2)统一的模板,并在接手旧项目先进行一次全面格式化,可以避免, 不同开发者之间,
因为格式不统一产生代码合并冲突,或者代码变更日志中因为格式不同引起的变更,掩盖
了真正的逻辑变更。
3)设定代码统一的行宽,建议 120。
4)设定代码统一的缩进方式(Tab 或二空格,四空格均可),基于 IDE 自动转换。
2.【强制】 IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格
式,不要使用 Windows 格式。
3.【推荐】 用小括号来限定运算优先级
if((a == b) && (c == d))
4.【推荐】 类内方法定义的顺序
1) 顺序依次是:构造方法 > (公有方法>保护方法>私有方法) > getter/setter 方法
2)当一个类有多个构造方法,或者多个同名的重载方法,这些方法应该放置在一起。其
中参数较多的方法在后面。
3)作为调用者的方法,尽量放在被调用的方法前面。
5.【推荐】 通过空行进行逻辑分段
int width;
int height;
String name;
6.【推荐】 通过注解避免 IDE 格式化对于特殊的场景下不需要进行 IDE 的格式化是,可
以使用@formatter:off 和@formatter:on 来包装这段代码,让 IDE 跳过它。需要注意
IDEA 是默认不开启该功能的,需要打开:Settings -> Editor -> Code Style ->
Formatter Control -> Enable xxxxxxxxxx
三、注释规范
1.【推荐】 基本的注释要求
1) 注释需要准确的反映设计思想及代码逻辑
2)公共的方法或抽象类的方法,尽可能描述清楚:输入、输出、错误处理和返回码、以及
可能抛出的异常。
3) 能够描述出业务的具体含义,使得读者能够快速了解代码背后的信息。
2.【推荐】 通过更清晰的代码来避免注释在编写注释之前,考虑是否可以通过更好的命
名,更清晰地代码结构,更好的函数和变量的抽取,让代码不言自明,此时不需要额外的
注释。
3.【推荐】 删除空注释,无意义注释《Clean code》建议,如果需要添加的说明,不需要
留着 IDE 自动生成的空的 @param,@return,@throw 标记
4.【推荐】 避免创建人,创建日期,及更新日志的注释通过 Git 等版本控制来记录更新
的信息
5.【强制】 代码修改的同时,注释也需要进行相应的修改。尤其是参数、返回值、异
常、核心逻辑等的修改
6.【强制】 类、类的公有成员,方法的注释必须使用 Javadoc 规范,使用/
* 注释
/格
式,不得使用//我是注释的方式。
7.【推荐】 注释不要为了英文而英文能用中文表达清楚就尽量使用中文注释
8.【推荐】 TODO 标记,清晰说明代办事项和处理人
9.【推荐】 合理处理注释掉的代码如果后续会恢复此段代码,在目标代码上方用///说
明注释动机,而不是简单的注释掉代码。如果很大概率不再使用,则直接删除(版本管理
工具保存了历史代码)。
四、方法设计
1.【推荐】 方法的长度限制方法尽量不要超过 100 行,需要注意的是方法长度超过 8000
个字节码时,将不会被 JIT 编译成二进制码。
2.【推荐】 方法的语句在同一个抽象层级上反例:一个方法里,前 20 行代码在进行很
复杂的基本价格计算,然后调用一个折扣计算函数,再调用一个赠品计算函数。
此时可将前 20 行也封装成一个价格计算函数,使整个方法在同一抽象层级上。
3.【推荐】 为了帮助阅读及方法内联,将小概率发生的异常处理及其他极小概率进入的
代码路径,封装成独立的方法
if(seldomHappenCase) {
hanldMethod();
}
try {
...
} catch(SeldomHappenException e) {
handleException();
}
4.【推荐】 尽量减少重复的代码,抽取公共方法。超过 5 行以上的重复代码,可以考虑
抽取成公用的方法。
剩余39页未读,继续阅读
资源评论
huver2007
- 粉丝: 370
- 资源: 39
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功