阿里巴巴Java开发规范手册
- 格式:pdf
- 大小:486.95 KB
- 文档页数:32
阿里巴巴开发规约1. 引言阿里巴巴开发规约是阿里巴巴集团在软件开发过程中的一套规范和准则,旨在提高代码质量、可维护性和可扩展性。
本规约适用于阿里巴巴集团内部的所有软件开发项目,并且也可以应用于其他公司和个人的软件开发过程中。
2. 规范目标阿里巴巴开发规约的主要目标是:•统一代码风格,提高代码可读性和易维护性;•提供一致的编码标准,降低代码错误率;•规范命名、注释和文档编写,便于项目交接和维护;•强调代码质量和安全性,避免常见的漏洞和攻击;•提供开发工具和插件支持,帮助开发人员快速定位问题。
3. 编码风格3.1 命名规范•类名使用大驼峰命名法,例如:UserInfoService。
•方法名使用小驼峰命名法,例如:getUserInfo。
•变量名使用小驼峰命名法,例如:userName。
•常量名使用全大写字母,单词间用下划线分隔,例如:MAX_RETRY_TIMES。
3.2 代码缩进和换行•使用4个空格进行缩进。
•每行代码不超过80个字符。
•长表达式可以在括号内换行,保持对齐。
3.3 注释规范•类、方法和变量的注释使用JavaDoc格式,并提供必要的说明。
•方法内部的注释使用单行或多行注释,解释方法的实现细节或注意事项。
•注释应该清晰、简洁,避免冗余和无用的注释。
4. 编码标准4.1 异常处理•不要捕获异常后不处理或者直接打印异常信息,应该根据具体情况进行处理或者抛出异常。
•不要在循环中捕获异常,应该将异常处理放到循环外部。
4.2 日志记录•使用合适的日志级别记录日志信息,避免过度记录和低级别日志混杂。
•使用参数化日志记录方式,避免字符串拼接带来的性能问题和安全隐患。
4.3 数据库操作•使用预编译语句(PreparedStatement)来执行SQL语句,避免SQL注入攻击。
•对于批量插入和更新操作,使用批处理(Batch)方式执行,提高性能。
4.4 安全性•避免使用不安全的加密算法和弱密码,使用安全性较高的算法和密码策略。
阿⾥巴巴开发规范学习学习编程规范的⽬标是为了编写出符合规范,具有可⽤性、可靠性和可维护的代码,进⽽创造出⾼质量的应⽤软件。
⼀、基本编程规约:1、命名规范:类名必须是驼峰命名,例如XmlSerevice、UserService。
2、⽅法名、变量名、参数名、局部变量统⼀为⼩驼峰命名,例如:getUserInfo()。
3、常量名全部⼤写,中间⽤下划线分隔,例如:MAX_NUMBER。
4、抽象类命名使⽤ Abstract 或 Base 开头;异常类命名使⽤ Exception 结尾;测试类命名以它要测试的类的名称开始,以Test结尾。
5、中括号是数组类型的⼀部分,数组定义如下:String[] args;6、POJO类中布尔类型的变量,都不要加 is,否则部分框架解析会引起序列化错误。
7、包名统⼀使⽤⼩写,点分隔符之间有且仅有⼀个⾃然语义的英语单词。
包名统⼀使⽤单数形式,但是类名如果有复数含义,类名可以使⽤复数形式。
8、接⼝类中的⽅法和属性不要加任何修饰符号(public也不要加),保持代码的简洁性,并加上有效的Javadoc注释。
尽量不要在接⼝⾥定义变量,如果⼀定要定义变量,肯定是与接⼝⽅法相关,并且是整个应⽤的基础常量。
例如接⼝⽅法:void f();9、对于Service和DAO类,基于SOA的理念,暴露出来的服务⼀定是接⼝,内部的实现类⽤Impl的后缀与接⼝区别。
例如:CacheServiceImpl实现CacheService接⼝。
10、枚举类名建议带上Enum后缀,枚举成员名称需要全⼤写,单词间⽤下划线隔开。
说明:枚举其实就是特殊的常量类,且构造⽅法被默认强制是私有。
例如:枚举名字:DealStatusEnum,成员名称:SUCCESS / UNKOWN_REASON。
11、给long或者Long初始赋值时,必须使⽤⼤写的 L,不能是⼩写的 l,⼩写容易跟数字1混淆,造成误解。
12、各层命名规约:A) Service/DAO 层⽅法命名规约1)获取单个对象的⽅法⽤ get 做前缀。
阿里开发者手册阿里开发者手册是阿里巴巴公司面向全球开发者发布的一系列文档和规范,旨在提高软件开发行业的规范性和质量。
该手册包括了软件开发、测试、部署等方面的最佳实践和规范,可帮助开发者更好地设计、编写和维护软件系统。
阿里开发者手册主要包含以下内容:**一. Java开发手册**Java开发手册详细说明了Java编程中的最佳实践和规范。
其包含的内容涵盖了Java开发的方方面面,如代码风格、异常处理、日志记录、注释、JVM参数调优等等。
Java开发手册被广泛认可,并已成为Java 开发行业的标准。
**二. 前端开发手册**前端开发手册是从前端工程师角度出发,为开发者提供了CSS、JavaScript、浏览器兼容性和网站性能优化等细节方面的最佳实践和规范。
前端开发手册提供了前端开发过程中必要的规范,能够提高代码的可读性及维护性。
**三. 微服务开发手册**微服务开发手册提供一组优秀的微服务设计原则,可以帮助开发者在使用微服务时降低系统的复杂度,提高系统的可伸缩性和可维护性。
该手册重点讲解了微服务架构中的最佳实践和规范,涵盖了微服务的架构、开发、部署和运维等方面。
**四. 安全开发手册**安全开发手册为开发者提供一系列的最佳实践和规范,帮助开发者在软件开发中重视信息和网络安全,避免因不恰当的代码和部署措施而导致的数据泄漏和系统崩溃等问题。
本手册涵盖即时通讯、网页安全、API等方面的安全问题,内容翔实且易懂。
**五. 数据库开发手册**数据库开发手册包含了数据库设计、应用程序处理的最佳实践和规范。
其中包括SQL编程、事务控制、数据模型设计与规范等方面的内容。
该手册提供了完整的数据库开发方法,使得开发者能更好的处理数据库方面的问题。
总的来说,阿里开发者手册是针对软件开发行业的严苛要求而编制的一系列规范和制度。
阅读手册有助于开发者了解行业的最新动态和发展趋势,有利于开发者规范化和优化自己的开发方式和技能。
alibaba java coding guidelines规则关于阿里巴巴Java编码规范规则的详细解析引言在Java开发中,编码规范是非常重要的,它不仅可以提高代码的可读性和可维护性,还有助于团队合作和代码的风格统一。
阿里巴巴作为中国最大的电商企业之一,拥有庞大的Java开发团队,为了统一团队的代码风格,提高代码质量,他们制定了一整套的Java编码规范,即阿里巴巴Java编码规范(下称“规范”)。
本文将以规范中的主题“[alibaba java coding guidelines规则]”为主线,逐条解析规范并给出相应的理解和实践建议。
一、规则一:命名规约1. 【强制】类名使用UpperCamelCase规范,方法名、成员变量名和局部变量名均使用lowerCamelCase规范。
命名规约是代码中最直观的内容之一,良好的命名规约可以提高代码的可读性和可维护性。
在使用UpperCamelCase和lowerCamelCase规范时,可以根据命名对象的特点选择合适的规范。
例如,类名通常代表一种抽象的概念,适合使用UpperCamelCase规范,而方法名、成员变量名和局部变量名通常代表具体的实现细节,适合使用lowerCamelCase规范。
2. 【强制】类名和方法名以功能命名,不以数据结构命名。
命名时应关注方法或类的功能,而不是内部的数据结构。
使用功能命名可以更好地描述代码的用途,并且随着代码的演进,内部的数据结构可以灵活变化而不会影响命名的准确性。
3. 【强制】定义枚举类型时,使用Enum后缀。
为了提高代码的可读性,对于枚举类型的定义,应统一添加Enum后缀。
例如:javapublic enum ColorEnum { ... }4. 【推荐】避免过长或过短的命名。
命名应该尽量精简明了,避免过长或过短的命名。
过长的命名可能会降低代码的可读性,而过短的命名则可能无法准确描述代码的含义。
5. 【推荐】对于常量和静态变量,使用全大写字母加下划线的命名规范。
阿里开发者手册1. 介绍阿里开发者手册是针对阿里巴巴公司的开发者群体编写的一份指导手册。
它提供了完整、详细、全面的技术文档和开发规范,帮助开发者在阿里巴巴的各个领域进行开发工作。
2. 规范与标准阿里开发者手册包含了丰富的规范与标准,涵盖了代码编写、项目管理、性能优化、安全防范等方面的要求。
下面是一些重要的规范与标准:2.1 代码规范•代码的命名规范,包括类名、方法名、变量名等的命名规则。
•代码的注释规范,包括注释的格式、注释的内容等要求。
•代码的缩进和空格规范,包括缩进的字符数、空格的使用等要求。
•代码的排版规范,包括括号的使用、换行的位置等要求。
2.2 项目管理规范•项目的目录结构规范,包括源代码目录、资源文件目录等的组织方式。
•项目的版本管理规范,包括分支管理、提交日志的编写等要求。
•项目的文档编写规范,包括需求文档、设计文档等的格式和内容要求。
•项目的测试规范,包括单元测试、集成测试等的执行方式和结果要求。
2.3 性能优化规范•代码的性能优化规范,包括循环优化、算法优化等方面的要求。
•数据库的性能优化规范,包括索引的使用、SQL语句的优化等要求。
•网络的性能优化规范,包括缓存的使用、CDN的配置等方面的要求。
•前端页面的性能优化规范,包括减少HTTP请求、压缩资源等的要求。
2.4 安全防范规范•代码的安全防范规范,包括输入验证、加密处理等方面的要求。
•网络的安全防范规范,包括防火墙的配置、权限管理等要求。
•数据存储的安全防范规范,包括数据库的加密、备份等方面的要求。
•静态资源的安全防范规范,包括防止恶意篡改、热更新等要求。
3. 使用与贡献阿里开发者手册提供了多种使用方式,方便开发者快速查阅和使用:3.1 在线阅读阿里开发者手册通过网站的形式提供在线阅读功能,开发者可以在任何地方、任何时间查阅相关内容。
3.2 下载使用开发者可以将阿里开发者手册下载到本地,方便离线查阅和使用。
下载的手册包含了完整的内容和相关资源。
阿里编程规范阿里编程规范是一套由阿里巴巴集团制定的软件开发规范,旨在统一阿里内部的代码风格,规范团队协作,提高代码的可读性、可维护性和可扩展性。
下面将从命名规范、代码风格、注释规范和异常处理等方面详细介绍阿里编程规范。
一、命名规范:1. 类和接口的命名使用大驼峰命名法,首字母大写,每个单词首字母大写。
例如:UserService。
2. 方法、变量和参数的命名使用小驼峰命名法,首字母小写,第二个单词开始每个单词首字母大写。
例如:getUserById(String userId)。
3. 常量的命名全部大写,单词间用下划线分隔。
例如:MAX_RETRY_TIMES。
4. 参数名和局部变量名使用有意义的英文单词或缩写。
例如:startIndex、endTime。
5. 包名使用小写字母。
二、代码风格:1. 缩进使用4个空格。
2. 每行代码长度不超过120个字符。
3. 行尾不添加多余的空白字符。
4. 大括号使用Java风格的换行规则,左大括号不另起一行。
5. 每个方法之间留一个空行,以提高可读性。
6. 类的成员变量声明在类的顶部,构造方法下方。
三、注释规范:1. 类、接口和方法前使用Javadoc注释,注释内容包括功能说明、参数、返回值和异常信息等。
2. 方法内部的重要步骤可以使用单行注释进行说明。
3. 注释要求简洁明了,不要过多解释显而易见的事情。
四、异常处理:1. 异常信息要具体、清晰,不要使用简单的错误信息。
2. 异常处理应该精确捕获,不要使用捕获所有异常的方式。
3. 捕获到异常后,可以进行日志打印和相关资源的清理工作。
阿里编程规范是一个非常详细严格的规范,对代码的规范性、可读性和可维护性要求非常高。
它为开发团队提供了统一的开发风格和指南,有利于团队协作和项目维护。
同时,阿里编程规范也是业界的佳作,对其他公司和个人的代码规范发展起到了积极的推动作用。
非常推荐开发者在开发过程中严格遵守阿里编程规范,以提高代码质量,减少潜在的bug风险。
《新版阿⾥巴巴Java开发⼿册》提到的三⽬运算符的空指针问题到底是个怎么回事?最近,阿⾥巴巴Java开发⼿册发布了最新版——泰⼭版,这个名字起的不错,⼀览众⼭⼩。
新版新增了30+规约,其中有⼀条规约引起了作者的关注,那就是⼿册中提到在三⽬运算符使⽤过程中,需要注意⾃动拆箱导致的NullPointerException(后⽂简称:NPE)问题:因为这个问题我很久之前(2015年)遇到过,曾经在博客中也记录过,刚好最新的开发⼿册再次提到了这个知识点,于是把之前的⽂章内容翻出来并重新整理了⼀下,带⼤家⼀起回顾下这个知识点。
可能有些⼈看过我之前那篇⽂章,本⽂并不是单纯的"旧瓶装新酒",在重新梳理这个知识点的时候,作者重新翻阅了《The Java Language Specification》,并且对⽐了Java SE 7 和 Java SE 8之后的相关变化,希望可以帮助⼤家更加全⾯的理解这个问题。
基础回顾在详细展看介绍之前,先简单介绍下本⽂要涉及到的⼏个重要概念,分别是"三⽬运算符"、"⾃动拆装箱"等,如果⼤家对于这些历史知识有所掌握的话,可以先跳过本段内容,直接看问题重现部分即可。
三⽬运算符在《The Java Language Specification》中,三⽬运算符的官⽅名称是Conditional Operator ? :,我⼀般称呼他为条件表达式,详细介绍在JLS 15.25中,这⾥简单介绍下其基本形式和⽤法:三⽬运算符是Java语⾔中的重要组成部分,它也是唯⼀有3个操作数的运算符。
形式为:<表达式1> ? <表达式2> : <表达式3>以上,通过?、:组合的形式得到⼀个条件表达式。
其中?运算符的含义是:先求表达式1的值,如果为真,则执⾏并返回表达式2的结果;如果表达式1的值为假,则执⾏并返回表达式3的结果。
阿里开发规约
阿里开发规约是阿里巴巴Java开发团队总结出的一套Java开发规范,它包括编码规约、异常日志规约、单元测试规约、安全规约等多个方面,旨在提高Java程序的可读性、可维护性、可扩展性和安全性。
下面是阿里开发规约的一些要点:
编码规约
命名规范:遵循驼峰命名法、使用有意义的变量名、方法名、类名等。
代码风格:缩进、空格、大括号、注释等要求统一规范。
异常处理:不要捕获异常后不处理,应该有明确的处理方式。
日志规约
日志级别:日志级别要根据实际情况选择。
日志格式:日志格式要清晰简洁,包括时间、日志级别、类名、方法名等。
日志记录:日志记录应该包含有用的信息,不要记录过多或无用的信息。
单元测试规约
测试方法:测试方法应该清晰明了、有明确的输入输出。
测试覆盖率:测试覆盖率要达到一定的要求,尽可能覆盖所有分支和路径。
测试数据:测试数据应该包含各种情况,例如正常情况、异常情况等。
安全规约
SQL注入:避免使用拼接SQL的方式,应该使用参数化查询。
XSS攻击:对用户输入的内容进行过滤、转义等处理。
密码安全:密码应该加密存储,且不要采用常见的密码,应该使用复杂的密码。
阿里开发规约的实践可以提高Java程序的代码质量,也有助于多人协作开发时代码的统一规范和风格。
前言《阿里巴巴Java开发手册》是阿里巴巴集团技术团队的集体智慧结晶和经验总结,经历了多次大规模一线实战的检验及不断完善,系统化地整理成册,回馈给广大开发者。
现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程知识点,其它维度的知识点也会影响到软件的最终交付质量。
比如:数据库的表结构和索引设计缺陷可能带来软件上的架构缺陷或性能风险;工程结构混乱导致后续维护艰难;没有鉴权的漏洞代码易被黑客攻击等等。
所以本手册以Java开发者为中心视角,划分为编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约七个维度,再根据内容特征,细分成若干二级子目录。
根据约束力强弱及故障敏感性,规约依次分为强制、推荐、参考三大类。
对于规约条目的延伸信息中,“说明”对规约做了适当扩展和解释;“正例”提倡什么样的编码和实现方式;“反例”说明需要提防的雷区,以及真实的错误案例。
本手册的旨在码出高效,码出质量。
现代软件架构的复杂性需要协同开发完成,如何高效地协同呢?无规矩不成方圆,无规范难以协同,比如,制订交通法规表面上是要限制行车权,实际上是保障公众的人身安全,试想如果没有限速,没有红绿灯,谁还敢上路行驶。
对软件来说,适当的规范和标准绝不是消灭代码内容的创造性、优雅性,而是限制过度个性化,以一种普遍认可的统一方式一起做事,提升协作效率,降低沟通成本。
代码的字里行间流淌的是软件系统的血液,质量的提升是尽可能少踩坑,杜绝踩重复的坑,切实提升系统稳定性,码出质量。
考虑到可以零距离地与众多开发同学进行互动,决定未来在线维护《手册》内容,此1.4.0的PDF版本,是最为详尽的版本,新增设计规约大章节,并增加若干条目;我们已经在2017杭州云栖大会上发布了阿里巴巴Java开发规约插件(点此下载),阿里云效(一站式企业协同研发云)也集成了代码规约扫描引擎。
最后,《码出高效——阿里巴巴Java开发手册详解》即将出版,敬请关注。
2)【推荐】如果是形容能力的接口名称,取对应的形容词做接口名(通常是–able的形式)。
正例:AbstractTranslator实现 Translatable。
14.【参考】枚举类名建议带上Enum后缀,枚举成员名称需要全大写,单词间用下划线隔开。
说明:枚举其实就是特殊的常量类,且构造方法被默认强制是私有。
正例:枚举名字:DealStatusEnum;成员名称:SUCCESS / UNKOWN_REASON。
15.【参考】各层命名规约:A) Service/DAO层方法命名规约1)获取单个对象的方法用get做前缀。
2)获取多个对象的方法用list做前缀。
3)获取统计值的方法用count做前缀。
4)插入的方法用save(推荐)或insert做前缀。
5)删除的方法用remove(推荐)或delete做前缀。
6)修改的方法用update做前缀。
B) 领域模型命名规约1)数据对象:xxxDO,xxx即为数据表名。
2)数据传输对象:xxxDTO,xxx为业务领域相关的名称。
3)展示对象:xxxVO,xxx一般为网页名称。
4) POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。
4.【推荐】常量的复用层次有五层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
1)跨应用共享常量:放置在二方库中,通常是client.jar中的const目录下。
2)应用内共享常量:放置在一方库的modules中的const目录下。
反例:易懂变量也要统一定义成应用内共享常量,两位攻城师在两个类中分别定义了表示“是”的变量:类A中:public static final String YES = "yes";类B中:public static final String YES = "y";A.YES.equals(B.YES),预期是true,但实际返回为false,导致产生线上问题。
3)子工程内部共享常量:即在当前子工程的const目录下。
4)包内共享常量:即在当前包下单独的const目录下。
5)类内共享常量:直接在类内部private static final定义。
5.【推荐】如果变量值仅在一个范围内变化用Enum类。
如果还带有名称之外的延伸属性,必须使用Enum类,下面正例中的数字就是延伸信息,表示星期几。
正例:public Enum{ MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}public static void main(String args[]) {// 缩进4个空格String say = "hello";// 运算符的左右必须有一个空格int flag = 0;// 关键词if与括号之间必须有一个空格,括号内f与左括号,1与右括号不需要空格if (flag == 0) {System.out.println(say);}// 左大括号前加空格且不换行;左大括号后换行if (flag == 1) {System.out.println("world");// 右大括号前换行,右大括号后有else,不用换行} else {System.out.println("ok");// 右大括号做为结束,必须换行}}6.【强制】单行字符数限制不超过120个,超出需要换行,换行时,遵循如下原则:1)换行时相对上一行缩进4个空格。
2)运算符与下文一起换行。
3)方法调用的点符号与下文一起换行。
4)在多个参数超长,逗号后进行换行。
5)在括号前不要换行,见反例。
正例:StringBuffer sb = new StringBuffer();//超过120个字符的情况下,换行缩进4个空格,并且方法前的点符号一起换行sb.append("zi").append("xin")….append("huang");反例:StringBuffer sb = new StringBuffer();//超过120个字符的情况下,不要在括号前换行sb.append("zi").append("xin")…append("huang");//参数很多的方法调用也超过120个字符,逗号后才是换行处method(args1, args2, args3, ..., argsX);7.【强制】方法参数在定义和传入时,多个参数逗号后边必须加空格。
正例:下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");8.【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。
正例:int a = 3;long b = 4L;float c = 5F;StringBuffer sb = new StringBuffer();说明:增加sb这个变量,如果需要对齐,则给a、b、c都要增加几个空格,在变量比较多的情况下,是一种累赘的事情。
9.【强制】IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式,不要使用windows格式。
10.【推荐】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。
相同业务逻辑和语义之间不需要插入空行。
说明:没有必要插入多行空格进行隔开。
3.【强制】相同参数类型,相同业务含义,才可以使用Java的可变参数,避免使用Object。
说明:可变参数必须放置在参数列表的最后。
(提倡同学们尽量不用可变参数编程)正例:public User getUsers(String type, Integer... ids);4.【强制】对外暴露的接口签名,原则上不允许修改方法签名,避免对接口调用方产生影响。
接口过时必须加@Deprecated注解,并清晰地说明采用的新接口或者新服务是什么。
5.【强制】不能使用过时的类或方法。
说明:.URLDecoder 中的方法decode(String encodeStr) 这个方法已经过时,应该使用双参数decode(String source, String encode)。
接口提供方既然明确是过时接口,那么有义务同时提供新的接口;作为调用方来说,有义务去考证过时方法的新实现是什么。
6.【强制】Object的equals方法容易抛空指针异常,应使用常量或确定有值的对象来调用equals。
正例:"test".equals(object);反例:object.equals("test");说明:推荐使用java.util.Objects#equals (JDK7引入的工具类)7.【强制】所有的相同类型的包装类对象之间值的比较,全部使用equals方法比较。
说明:对于Integer var=?在-128至127之间的赋值,Integer对象是在IntegerCache.cache 产生,会复用已有对象,这个区间内的Integer值可以直接使用==进行判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑,推荐使用equals方法进行判断。
8.【强制】关于基本数据类型与包装数据类型的使用标准如下:1)所有的POJO类属性必须使用包装数据类型。
2) RPC方法的返回值和参数必须使用包装数据类型。
3)所有的局部变量推荐使用基本数据类型。
说明:POJO类属性没有初值是提醒使用者在需要使用时,必须自己显式地进行赋值,任何NPE问题,或者入库检查,都由使用者来保证。
正例:数据库的查询结果可能是null,因为自动拆箱,用基本数据类型接收有NPE风险。
反例:某业务的交易报表上显示成交总额涨跌情况,即正负x%,x为基本数据类型,调用的RPC服务,调用不成功时,返回的是默认值,页面显示:0%,这是不合理的,应该显示成中划线-。
所以包装数据类型的null值,能够表示额外的信息,如:远程调用失败,异常退出。
9.【强制】定义DO/DTO/VO等POJO类时,不要设定任何属性默认值。
反例:某业务的DO的gmtCreate默认值为new Date();但是这个属性在数据提取时并没有置入具体值,在更新其它字段时又附带更新了此字段,导致创建时间被修改成当前时间。
10.【强制】序列化类新增属性时,请不要修改serialVersionUID字段,避免反序列失败;如果完全不兼容升级,避免反序列化混乱,那么请修改serialVersionUID值。
说明:注意serialVersionUID不一致会抛出序列化运行时异常。
11.【强制】构造方法里面禁止加入任何业务逻辑,如果有初始化逻辑,请放在init方法中。
12.【强制】POJO类必须写toString方法。
使用工具类source> generate toString时,如果继承了另一个POJO类,注意在前面加一下super.toString。
说明:在方法执行抛出异常时,可以直接调用POJO的toString()方法打印其属性值,便于排查问题。
13.【推荐】使用索引访问用String的split方法得到的数组时,需做最后一个分隔符后有无内容的检查,否则会有抛IndexOutOfBoundsException的风险。
说明:String str = "a,b,c,,"; String[] ary = str.split(",");//预期大于3,结果是3System.out.println(ary.length);14.【推荐】当一个类有多个构造方法,或者多个同名方法,这些方法应该按顺序放置在一起,便于阅读。
15.【推荐】类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter/setter方法。
说明:公有方法是类的调用者和维护者最关心的方法,首屏展示最好;保护方法虽然只是子类关心,也可能是“模板设计模式”下的核心方法;而私有方法外部一般不需要特别关心,是一个黑盒实现;因为方法信息价值较低,所有Service和DAO的getter/setter方法放在类体最后。
16.【推荐】setter方法中,参数名称与类成员变量名称一致,this.成员名=参数名。