文档介绍：Java开发手册
目录
前言 3
一、 编程规约 4
(一) 命名规约 4
(二) 常量定义 6
(三) 格式规约 7
(四) OOP 规约 8
(五) 集合处理 11
(六) 并发处理 14
(七) 控制语句 16
(八) 注释规约 17
(九) 其它 18
二、 异常日志 19
(一) 异常处理 19
(二) 日志规约 21
三、 MySQL 规约 22
(一) 建表规约 22
(二) 索引规约 23
(三) SQL 规约 25
(四) ORM 规约 26
四、 工程规约 27
(一) 应用分层 27
(二) 二方库规约 28
(三) 服务器规约 29
五、 安全规约 30
六、 附1:本规约专有名词 30
Java 开发手册
前言
《Java 开发手册》是某著名集团技术团队的集体经验总结,经历了
多次大规模一线实战的检验及不断的完善,反馈给广大开发者。现代软件行业的高速
发展对于开发者的综合素质要求越来越高,因为不仅是编程知识点,其它维度的知识
点也会影响到软件的最终交付质量。比如:数据库的表结构和索引设计缺陷可能带来
软件上的架构缺陷或性能风险;工程结构混乱导致维护困难;没有鉴权的漏洞代码被
黑客攻击等等。所以本手册以 Java 开发者为中心视角,划分为编程规约、异常日志规
约、MySQL 规约、工程规约、安全规约五大块,再根据内容特征,细分成若干二级子目
录。根据约束力强弱及故障敏感性,规约依次分为强制、推荐、参考三大类。对于规
约里的内容,“说明”对内容做了引申和解释;“正例”提倡什么样的编码和实现方
式;“反例”说明需要提防的雷区,以及真实的错误案例。
本手册的愿景是码出质量、码出高效。代码的字里行间流淌的是软件生命中的血液,质量的提升是尽可能少踩坑,杜绝踩重复的坑,切实提升质量意识。另外,现代软件架构都需要协同开发完成,高效考虑的是降低协同成本,所谓无规矩不成方圆,无规范不能协作。众所周知,制订交通法规表面上是要限制行车权,实际上是保障公众的人身安全。试想如果没有限速,没有红绿灯,没有规定靠右行驶,谁还敢上路行驶。对软件来说,适当的规范和标准绝不是消灭代码内容的创造性、优雅性,而是限制过度个性化,以一种普遍认可的统一方式一起做事,提升协作效率。
Java 开发手册
版本号
制定团队
更新日期
备注
增加前言和专有名词说明,修正部分描述。
编程规约
(一) 命名规约
【强制】代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。反例: _name / __name / $Object / name_ / name$ / Object$
【强制】代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式也要避免采用。
反例: DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量= 3 正例: alibaba / taobao / youku / hangzhou 等国际通用的名称,可视同英文。
【强制】类名使用 UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外:(领域模型
的相关命名)DO / BO / DTO / VO 等。
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必须遵从驼峰形式。
正例: localValue / getHttpMessage() / inputUserId
【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。正例: MAX_STOCK_COUNT
反例: MAX_COUNT
【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾;测试类命名以它要测试的类的名称开始,以 Test 结尾。
【强制】中括号是数组类型的一部分,数组定义如下:String[] args; 反例:使用 String args[]的方式来定义。
【强制】POJO 类中布尔类型的变量,都不要加 is,否则部分框架解析会引起序列化错误。反例:定义为基本数据类型 Boolean ess;的属性,它的方法也是 ess(),RPC
框架在反向