一些项目的代码开发规范

1. 命名规范

1.1 类名规范

• 驼峰原则、首字母必须大写
• 不允许使用下划线和数字（涉及版本号的APP接口相关类除外）
• 禁止使用拼音和自定义缩写（jiuhong和taobao之类约定俗成的拼音可以使用）
• 应采用完整的单词，避免使用意义不明确的缩写。
• 持久层接口以Dao结尾，业务层类Service结尾，Controller层以Controller结尾。
• 有书写错误的类需要及时改正并提交版本管理系统。

注意：此项目的Service层没有接口

1.2 方法名、变量名规范

• 驼峰原则、首字母必须小写
• 不允许使用下划线，禁止使用拼音和自定义缩写（jiuhong和taobao之类约定俗成的拼音可以使用）。
• 应采用完整的单词，避免使用意义不明确的缩写。
• 持久层方法名以save、delete、update、get、select为前缀；
• 方法名和属性名应保证见名知义，不要怕长。
• 有书写错误的类需要及时改正并提交版本管理系统。

正确示例：registerByMobileNumber
错误示例：RegisterByMobileNumber 首字母未小写
错误示例：registerbymobilenumber 未遵循驼峰原则
错误示例：registerByMobNum 滥用自定义缩写
错误示例：shouJiHaoZhuCe 使用拼音
错误示例：registerByFool 随便起名字、见名不知义

• 原则上所有重载方法都是实现同一个功能，只是接收不同的参数。因此，禁止将重载方法用于完全不同的功能。如果需要实现不同的功能，应使用其他方法名。
• 常量要求所有字母必须大写、单词之间以下划线分隔

正确示例: FUIOU_REALNAME_ERROR
错误示例：fuiouRealnameError 未全部大写
错误示例：FUIOUREALNAMEERROR 未使用下划线分隔单词

1.3 字面量规范

• Float/float类型字面量使用F结尾
• Long/long类型字面量使用L结尾
• 不允许使用小写字母结尾
• Double/double和Integer/int类型字面量不要加后缀。

正确示例：8.0F、40L
错误示例：8.0f、40l 后缀小写
错误示例：8.0D、8.0d、40I、40i 不应该加后缀的字面量

1.4 包名规范

• 包名应全部使用小写字母
• 避免使用拼音、缩写以及拼音缩写
• 尽量使用一个单词表达包的内容
• 如果超过一个单词，单词间不必使用下划线分隔。
• 拼写错误应及时纠正。

正确示例：allinpay
错误示例：xinxipiluo 使用拼音、拼写错误
错误示例：msgcl 使用缩写、拼音缩写

2. 代码格式规范

2.1 类的继承和代码规范

• 实体类简化代码：所有实体类统一使用lombok进行代码简化，包括@Data和@EqualsAndHashCode(callSuper = true)注解。
• 各层代码继承统一父类 Controller层继承BaseController，Service类继承BaseService接口，Dao层继承BaseDao接口。
• 使用注解 使用@Controller、@Service注解标注各层
• 所有数据库表对应的实体类，基本数据类型应使用包装类，以涵盖数据值为null的情况。

2.2 方法代码规范

• 一个方法长度原则上不允许超过80行，严禁超过150行，不符合要求的方法需要精简代码或提取方法等。
• 不同逻辑的代码之间加一个空行来保证可读性。
• 任何重写父类的方法需要添加@Override注解。
• 任何equals方法需要将字面量放在前面，以规避空指针风险。

正确示例： “1”.equals(something)
错误示例： something.equals(“1”)  

• 判断字符串为空时，需使用spring包的StringUtils.isEmpty方法，不允许使用其他包的方法。
• 判断集合为空时，需使用spring包的CollectionUtils.isEmpty方法。
• 注掉的代码应及时清除，避免不断堆砌无用的垃圾，版本管理系统上已经保存了所有的修改痕迹，需要恢复代码时，到版本管理系统上去寻找历史版本的代码。
• 超过10行的重复代码必须提取公共方法。
• 需要修改的方法应在原方法基础上修改，不允许另外创建形如XXX1、XXX2、XXX3之类的类、方法以及页面。

3. 注释规范

3.1 Javadoc注释

• Javadoc注释，新建的类应添加类的javadoc注释，包含创建时间、创建人以及类的用途。
• 类中的属性需添加javadoc注释注明其含义。
• 接口和类中的方法需添加javadoc注释注明方法含义、方法返回值含义、复杂方法参数含义；接口中方法的注释需详细清晰。

3.2 段注释

• 复杂逻辑代码段含义应使用java段注释进行分隔，表明当前逻辑段的含义。

3.3 行注释

• 正常的代码语句应使用java行注释进行注释，表明当前语句的逻辑含义。
• 除本身能准确反应含义的语句和简单声明或赋值语句外，其他语句均需添加注释。

4. 日志规范

• 除临时调试外，严禁使用System.out.println()打印日志。调试用的System.out.println()语句应及时清除。
• 生产环境日志级别设置为info，因此需要在生产环境打印日志的级别应该是info级别以上（info、warn、error），不能使用debug级别。
• 捕捉异常不允许使用e.printStackTrace()方法，应使用logger.error方法代替。
• Controller层代码在接收请求的方法首行应打印日志，标明方法处理的业务以及请求的参数。
• 复杂逻辑段应打印日志，清晰表明逻辑段的中间过程。
• 涉及敏感业务的代码，应清晰打印日志，表明业务的整个流转过程，同时应在数据库中进行相应的业务记录。
• 涉及与第三方交互的代码，应清晰打印日志，表明请求的输入和输出，应包含请求是否成功、失败时错误码和错误信息等内容。
• 其他逻辑重要的代码自行打印日志进行记录。

5. 数据库规范

• 表名和列名应见名知义，同时遵循下划线原则，即单词间使用下划线分隔
• 表名应尽量精简清晰。
• 表名和Java实体类名应清晰的对应，而不应采用两套没有关系的命名。
• 视图名应以v_开头，表名应避开以v_开头。
• 表名：模块名_业务名，非系统模块不要以sys开头
• 列名：单词间以下划线分隔，所有字母小写，防止跨环境部署时出错
• 列名不宜过长，应见名知义，与实体类的字段名应严格遵守驼峰和下划线的对应关系
• 列名尽量采用完整的单词，避免使用意义不明确的缩写

正确示例：表名invest_repay 列名 current_invest_time
错误示例：表名investrepay 列名 currentinvesttime 未使用下划线
错误示例：表名calcinvestrepaystepone 表名过长，未使用下划线

• 新建表时，应遵循数据库设计的第三范式，即不允许在新表中重复存储可以从其他表中获取的信息。

错误示例：claim表中的字段大多数是可以从其他表中获取的信息。
错误示例：需要记录用户的表中重新存储用户名、身份证号等。
正确示例：如需记录用户信息，应与o_user表进行关联，新表中仅存储id字段。

• 新建表时或新增列时必须增加表和列的注释，注释应简明清晰，有不同取值的类，应注明不同取值的含义。
• 表中表明状态的列，应使用数字代表不同状态，不应该直接使用字符串 （字符串检索效率较低）。

正确示例 status 0/1  // 0-正常 1-已删除 
错误示例 status 正常/已删除

6. 版本管理规范

• 代码提交SVN时，必须书写注释，注释应详细解释代码修改点，以便以后查阅。
• 提交代码前应先进行更新，避免提交代码时冲突。
• 不要上传配置文件，包括IDE相关的项目文件、本地的jdbc配置、第三方交互配置等，新建的配置文件除外。

7. 注意事项

此规范随项目进行不断更新，有更新时请各位开发人员及时查看。