Java编程风格主题分享

Java编程风格主题分享

为什么要有编程风格?

      好的代码风格应当是优雅的！
      优雅高效的代码，代码逻辑直接了当，叫缺陷难以隐藏，尽量减少依赖关系，便于维护；依据某种分层战略完善错误处理代码，性能调至最优，省的引诱别人做没规矩的优化，搞出一堆混乱。
      整洁的代码简单直接，整洁的代码从不隐藏设计者的意图，充满干净利落的抽象和直截了当的控制语句整洁的代码应可由作者之外的开发者阅读和增补。应当有单元测试和验收测试。它使用有意义的命名，它只提供一种而非多种做一件事的途径。他只有尽量少的依赖关系，而且要明确的定义和提供清晰、尽量少的API。代码应当通过其字面表达含义，因为不同的语言导致并非所有必须信息均可通过代码自身清晰表达。
      整洁代码整洁的代码总是看起来像是某位特别在意他的人写的。几乎没有更改的余地。在意代码能够通过测试没有重复代码体现系统中的全部设计理念包括尽量少的实体，比如类、方法、函数如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让变成语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码
      所以好的编程风格能够使代码结构清晰、让代码是自注释的、能够让自己看懂以前的代码、看懂同事的代码、让同事看懂自己的代码、快速看懂代码。

---

1. 代码通用命名

      命名应名副其实，避免误导，做有意义的区分。要区分名称，就要以读者能鉴别不同之处的方式来区分，使用可读出来的名称，使用可搜索出来的名称，名称长短与其作用域大小相对应，不应当让读者在脑中把你的名称翻译为他们熟知的名称。
      命名应避免思维映射，明确是王道，有意义的命名，类名名词或名词短语，方法名动词或动词短语。每个概念对应一个词，避免将同一个单词用于不同的目的。别用双关语遵循“一词一义”规则，使用解决方案领域名称，使用源自所涉问题领域的名称，添加有意义的语境。
      命名短小，只做一件事，每个函数一个抽象层级。自顶向下读代码：向下规则使用描述性的名称函数短小，功能越集中，越便于起个好名，一元函数标识参数标识true、false，二元函数函数函数参数，三元函数参数对象参数列表，无副作用分割指令与询问，使用异常代替返回错误码。

1） 不要使用数字、下划线、特殊字符开头 代码中的命名均不能以下划线或美元符号开始，也不能以此结束；

2） 严禁中英文结合，更不允许直接使用英文；

3） 不要使用拼音

4） 不要使用用无意义的命名：int a,b；Project project1，project2

5） 尽量表达意图 最好言意感

6） 使用大家都知道的缩写，不要自己造缩写

7） 类名使用驼峰形式，但DO/BO/DTO/VO除外；后缀如POJO应全部大写 不应使用驼峰命名

8） 方法名、参数名、成员变量、局部变量统一使用驼峰；

9） 常量名全部大写，单词间下划线隔开，不嫌名长，力求语义表述完整

10） 杜绝不规范缩写，避免歧义

11） 包名全小写

12） 如果用到了设计模式，类名中体现出具体模式，如：xxxFactory

13） 接口中，方法和属性不要加任何修饰符，并加上java doc注释

14） 重写或实现方法时，加@Overide注解

15） 开发过程中重命名，可能导致不想重命名的文件修改 在重命名时需要查看相关修改项，小范围手动修改

16） 转换可以 用2代替To

17） MVC各层命名规约

Service/Dao层
• 获取单个对象 get 前缀
o 获取多个对象 list 前缀
o 获取统计值的方法 count 前缀
o 插入 save 前缀
o 删除 remove
o 修改 update

2. 代码注释

1） 类，类属性，类方法，枚举，枚举项，使用javadoc规范注释：/*注释/

2） 注释请使用中文

3） 类注释请加创建人与创建时间

4） 方法逻辑有修改，请一起修改注释

5） 简单业务，方法名已经代表含义，可不加注释

6） 复杂业务必须加注释

7） 方法中的业务有明显分层的请使用空行隔开，并为每层业务加简单注释说明

8） 类、类属性、类方法的注释必须使用/*内容/格式；不得使用//xxx方式；

9） 方法内部单行注释，在被注释语句上方另起一行，使用 // 注释；方法内部多行注释使用 /* */注释；

10） 注释掉的代码，尽量详细说明一下原因；如果代码无用，直接删除；

11） 注释不能美化糟糕的代码

3. 代码结构

1） 属性之间，方法之间，属性与方法之间建议有一个空行隔开

2） 一个类中的代码显示层级：属性>构造器>公共方法>保护方法>私有方法>内部类>setter&getter

3） 控制，循环语句即使只有一行代码也要使用{}包裹

4） switch语句中每一个case语句请根据情况使用break；return；跳出循环，必须以default收尾

5） 一行代码过长请折行

6） 链式调用请折行

7） 复杂的判断请抽取成一个易懂的变量名或方法

4. 文件编码

【强制】 所有文本文件请设置编码为UTF-8

5. Java包

1） 包名全部小写

2） 包名每一层级尽量用一个单词：com.gpf.xmxx.order

3） 必须使用多个单词的情况，之间不要有大写：com.gpf.xmxx.common.fileserver

4） 组织项目包结构前缀：org.组织名项目名

5） 公司公司包结构前缀：com.公司名.项目名

6） 业务接口包service

7） 业务服务包server

8） 业务模型包mode1

9） 业务通用包common

10） 业务工具包util

11） 业务持久层包dao

12） 业务持久层复杂逻辑包manager

13） 业务控制层包controller

14） 业务Http接口层包api

6. Java类

1） 类名格式：首字母大写驼峰格式

2） 普通类名一般是一种事物：Dog Order Project

3） 接口类名一般是行为角色：Executor CacheManager Handler Roulapper Flyable

4） 按口实现类请尽量以按口名为后缀：RediscacheManger UserRowMapper

5） 抽象类以Abstract开头

6） 业务接口类以 Service结尾

7） 业务接口实现类以5erviceImp1结尾复杂持久层逻辑类以manager结尾

8） 业务控制层以controller结尾

9） 业务Http接口层以Api结尾

10） POJ0类以BO|VO|DTO|Query|FormlParam结尾 POJO后缀不要书写驼峰 全部大写

11） 如果使用了设计模式，尽量加设计模式后缀：Proxy lFactory lstrategy lcommondlIterator

12） 在重写和实现 一定要加@Override

13） 代码结构应当自治 不要给大家添麻烦

14） 代码编写顺序需要统一 如:先属性后方法 先GET后POST 方便阅读

7. 工具类

1） 工具类使用final修饰类名

2） 工具类构造函数必须私有

3） 通用工具类以util结尾：Cacheutil Dictutil stringutil

4） 通用工具类必须与业务无关

5） 业务工具类以业务类名加s后缀：Dogs Orders Projects collections Arrays

6） 业务工具类必须和业务模块在一起

7） 业务工具类只跟该业务有关

8） 优先考虑业务工具类，避免通用工具类

8. Java属性与方法

1） 属性|方法名：首字母小写驼峰格式

2） 常量属性：全部大写，多单词以下划线隔开：BATCH PAGE_SIZE

3） 多个常量属于一个范畴，使用范畴前缀与其他进行区分：

4） REQUEST_USER,REQUEST_DICT,DATE_YEAR,DATE_MONTH,DATE_DAY

5） 接口中的属性和方法不需要加public abstrict static final修饰符

6） 属性引用尽量使用接口、抽象类而不是实现

7） 方法名一定要表达方法含义、精简（含义优先）

8） 业务接口中操作业务的方法名一般不需要包含业务名称，因为有业务类名的限定。如projectservice.getProject->projectservice.get

9） 参数名尽量表达出参数的含义：Project updateproject；Project insertProject；Project detail；ProjectAccountVirtualPhone bindInfo；AccountVirtualPhone callInfo

9. 配置

1） 配置文件中的配置命名：应用名。模块名。业务名。属性，如：
xmxx.db.xs.jdbc.ur1；xmxx.common.fileserver.ali.host；xmxx.account.server.virtualphone.huawei.h ost；xmxx.web.portal.session.redis.namespace；

2） 配置类可以以config、property结尾

3） 全局配置与具体业务无关

4） 业务需要配置，请单独写一个业务配置

5） 业务配置类只负责该业务配置

6） 【推荐】不要使用一个常量类维护所有的常量，应该按常量功能进行归类，分开维护；常量的分类层次问题；

10. 数据库

1） 各种名称全部小写，多单词用隔开

2） 数据库名：db业务

3） 表名不要使用复数

4） 一组业务表统一使用相关业务前缀：order,order_product,order_status

5） 唯一索引使用uk开头：uk_email

6） 普通索引使用idx开头

7） 【强制】使用count(*) 来统计行数，不要使用 count( 列名 ) 或 count(常量) 来替代 count(*)。

count(*) 就是 SQL 92 定义
的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
说明： count(*) 会统计值为 NULL 的行，而 count( 列名 ) 不会统计此列为 NULL 值的行。

8） 【强制】 count(distinct col) 计算该列除 NULL 之外的不重复数量。注意 count(distinct

col 1, col 2 ) 如果其中一列全为 NULL ，那么即使另一列有不同的值，也返回为 0。

9） 【强制】当某一列的值全是 NULL 时， count(col) 的返回结果为 0，但 sum(col) 的返回结果为

NULL ，因此使用 sum() 时需注意 NPE 问题。
正例：可以使用如下方式来避免 sum 的 NPE 问题： SELECT IF(ISNULL(SUM(g)) ,0, SUM(g))
FROM table;

10） 【强制】使用 ISNULL() 来判断是否为 NULL 值。注意： NULL 与任何值的直接比较都为 NULL。
说明：

① NULL<>NULL 的返回结果是 NULL ，而不是 false 。
② NULL =  NULL 的返回结果是 NULL ，而不是 true 。
③ NULL<>1 的返回结果是 NULL ，而不是 true 。

11） 小数类型为decimal、禁用float和double；

12） varchar，长度不要超过5000；如果存储长度大于此值，定义为text，独立出一张表，避免影响其它字段的索引效率；

13）为了可读性，SQL代码应当在Navicat中进行美化

11.OOP规约

1） Object的equals方法容易抛出空指针异常，应使用常量或者确定有值的对象来调用equals；

12.集合处理

1） 不要在foreach循环中进行元素的remove/add操作；remove元素请使用Iterator方式，如果并发操作，需要对Iterator对象加锁；

2） 使用entryset遍历map集合，而不是keyset；

keyset其实是遍历了2次，一次是转为Iterator对象，；另一次是从hashmap中取出key所对应的value；而entryset只是遍历了一次就把key和value都放到了entry中；

3） 利用set集合元素的唯一性，而不是list的contains方法；

13.控制语句

1） if/else/for/while/do语句中必须使用大括号，即使只有一行代码；

2） 及时的判空操作

3） 不要在条件判断中执行复杂的语句；可以定义一个布尔类型的变量去执行逻辑判断；

4） 循环体的语句要考虑性能；

5） 减少if-else嵌套层数（不超过3层）

6） if不要太复杂，少用if-else； 快速结束 可以改写为if。。return}。。；

7） switch case 一般要有break;防止case 穿透 必须要以default收尾；

14.异常处理

1） 避免抛出exception异常，应使用含有业务含义的自定义异常；

2） 对于runtimeexception，尽量通过预先检查来规避；

3） 防止NPE问题；

15.工程规约

1） Object的equals方法容易抛空指针异常，使用常量或确定有值的对象来调用 equals方法

2） 当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读

3） 类内方法定义顺序依次是：公有方法或保护方法 -> 私有方法 -> getter/setter方法

4） 循环体内，字符串的联接方式，使用 StringBuilder 的 append 方法进行扩展（JDK8编译器已优化）

5） 集合初始化时，如果能预估集合大小，尽量指定集合初始值大小

6） 如果自定义对象做为 Map 的键，那么必须重写 hashCode 和 equals（尽量使用java定义的对象做键）

7） 避免使用List的contains方法，用Set代替之

16.杂项补充

1） 尝试开始做单元测试

2）不要在控制器中直接调用dao层接口；

3） IDEA 阿里巴巴代码规约插件

4） 编码中在比较等操作 确定值放前面

5） 公共类注明何时需要被继承

6） 及时更新不用代码@Deprecated

7） 在调用(使用)第三方接口 最好标记正确 or 错误 的示例结果 官方接口地址和帮助文档地址

8） 代码在提交之前应当格式化，应当只格式化自己提交的代码 防止冲突

附录

本次分享内容附件:
[阿里巴巴编程规约v1.4]
代码整洁之道CleanCode(清晰度一般)

百度云 链接: https://pan.baidu.com/s/1oI7Sm7Y64modrnjvIpTH7w 密码: nbcw