文档介绍：Java开发手册前言现代软件行业的高速发展对于开发者的综合素质要求越来越高,因为不仅是编程知识点,其它维度的知识点也会影响到软件的最终交付质量。比如:数据库的表结构和索引设计缺陷可能带来软件上的架构缺陷或性能风险;工程结构混乱导致维护困难;没有鉴权的漏洞代码被黑客攻击等等。所以本手册以Java开发者为中心视角,划分为编程规约、异常日志规约、MySQL规约、工程规约、安全规约五大块,再根据内容特征,细分成若干二级子目录。根据约束力强弱及故障敏感性,规约依次分为强制、推荐、参考三大类。对于规约里的内容,“说明”对内容做了引申和解释;“正例”提倡什么样的编码和实现方式;“反例”说明需要提防的雷区,以及真实的错误案例。本手册的愿景是码出质量、码出高效。代码的字里行间流淌的是软件生命中的血液,质量的提升是尽可能少踩坑,杜绝踩重复的坑,切实提升质量意识。另外,现代软件架构都需要协同开发完成,高效考虑的是降低协同成本,所谓无规矩不成方圆,无规范不能协作。众所周知,制订交通法规表面上是要限制行车权,实际上是保障公众的人身安全。试想如果没有限速,没有红绿灯,没有规定靠右行驶,谁还敢上路行驶。对软件来说,适当的规范和标准绝不是消灭代码内容的创造性、优雅性,而是限制过度个性化,以一种普遍认可的统一方式一起做事,提升协作效率。一、编程规约(一)命名规约1.【强制】代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。反例:_name/__name/$Object/name_/name$/Object$2.【强制】代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式也要避免采用。反例:DaZhePromotion[打折]/getPingfenByName()[评分]/int某变量=3正例:alibaba/taobao/youku/hangzhou等国际通用的名称,可视同英文。3.【强制】类名使用UpperCamelCase风格,必须遵从驼峰形式,但以下情形例外:(领域模型的相关命名)DO/BO/DTO/VO等。正例:MarcoPolo/UserDO/XmlService/TcpUdpDeal/TaPromotion反例:macroPolo/UserDo/XMLService/TCPUDPDeal/TAPromotion4.【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格,必须遵从驼峰形式。正例:localValue/getHttpMessage()/inputUserId5.【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。正例:MAX_STOCK_COUNT反例:MAX_COUNT6.【强制】抽象类命名使用Abstract或Base开头;异常类命名使用Exception结尾;测试类命名以它要测试的类的名称开始,以Test结尾。7.【强制】中括号是数组类型的一部分,数组定义如下:String[]args;反例:使用Stringargs[]的方式来定义。8.【强制】POJO类中布尔类型的变量,都不要加is,否则部分框架解析会引起序列化错误。反例:ess;的属性,ess(),RPC框架在反向解析的时候,“以为”ess,导致属性获取不到,进而抛出异常。9.【强制】包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。正例:.、类名为MessageUtils(此规则参考spring的框架结构)10.【强制】杜绝完全不规范的缩写,避免望文不知义。反例:AbstractClass“缩写”命名成AbsClass;condition“缩写”命名成condi,此类随意缩写严重降低了代码的可阅读性。11.【推荐】如果使用到了设计模式,建议在类名中体现出具体模式。说明:将设计模式体现在名字中,有利于阅读者快速理解架构设计思想。正例:lassOrderFactory;lassLoginProxy;lassResourceObserver;12.【推荐】接口类中的方法和属性不要加任何修饰符号(public也不要加),保持代码的简洁性,并加上有效的Javadoc注释。尽量不要在接口里定义变量,如果一定要定义变量,肯定是与接口方法相关,并且是整个应用的基础常量。正例:接口方法签名:voidf();接口基础常量表示:PANY="alibaba";反例:接口方法定义:publicabstractvoidf();说明:JDK8中接口允许有默认实现,那么这个default方法,是对所有实现类都有价值