前言
开发的时候，还是要遵守一些规范的，不然代码看起来杂乱无章，毫无美感，一个有规范的代码，看起来就不像屎山，成为大佬的第一步，你的代码得有规范，下面我们一起来看看代码规范的那些事。
命名规范
命名规范是最最最常见的规范，好的命名是代码的第一步，应做到“见名知意”。
1、类名与接口名: 使用大驼峰式，比如UserService, OrderInfo, UserInfoDTO
2、方法名与变量名: 使用小驼峰式，比如calculateTotalPrice(), userName, getStudentName()
3、常量名: 全部大写，单词间用下划线分隔，比如MAX_RETRY_COUNT, DEFAULT_TIMEOUT_MS
4、包名: 全部小写，避免使用下划线，比如com.example.myproject
注意：
- 对于布尔类型，为避免部分序列化框架解析异常，建议不要以 is 开头，可以使用 deleted, hasPermission, canEdit 等形式。
- 避免无意义命名: 严禁使用拼音、拼音首字母或 a, b, tmp 等无意义字符命名。
格式规范
现在基本都用编程工具idea啥的开发，格式都大差不差，这里不做详细讲解，适当换行，保持代码整洁就行。
注释规范
说明其功能、参数、返回值和可能抛出的异常
简单例子
/** * 计算两个数的和。 * @param a 第一个加数 * @param b 第二个加数 * @return 两数之和 */public int add(int a, int b) { return a + b;}代码结构
- 单一职责原则: 一个类或方法只负责一项功能
- 方法长度: 单个方法的行数建议不超过 80 行
- 一些能提取出来公用方法，就提取出来，避免过多冗余代码
springboot开发规范
上一篇已经讲过结构规范，这里不再重复说明。
类型 | 命名规则 | 示例 |
Controller 类 | 名词 + Controller | UserController |
Service 接口 | 名词 + Service | OrderService |
Service 实现 | 名词 + ServiceImpl | OrderServiceImpl
|
实体类 | 名词（单数） | User, Product |
Repository/DAO | 名词 + Repository 或 Mapper | UserRepository |
配置类 | 名词 + Config 或 Configuration | WebConfig |
工具类 | 名词 + Util 或 Utils | DateUtil, StringUtils |
异常类 | 名词 + Exception | CustomException |
- Controller层规范
- 职责单一：Controller 不应包含复杂的业务逻辑、数据校验（除了简单的参数校验）或数据库操作。所有业务都应委派给 Service 层。
- 建议遵循 RESTful 设计：使用 GET（查询）、POST（创建）、PUT（更新）、DELETE（删除）等标准方法来定义操作
- 统一响应格式：所有接口应返回统一格式的响应体，通常包含 code（状态码）、message（消息）和 data（数据）字段。
- 统一异常处理：使用 @ControllerAdvice 和 @ExceptionHandler 进行全局异常捕获和处理，避免在 Controller 中编写大量的 try-catch 代码，并确保返回统一的错误格式。
2.Service层规范
- 事务边界：@Transactional 注解应加在 Service 层的方法上，而不是 Controller 或 Repository 层。对于查询操作，可以设置 @Transactional(readOnly = true) 以优化性能。
- 依赖注入：强制使用构造函数注入，而不是 @Autowired 字段注入。这能确保依赖的不可变性和便于单元测试。
- 避免臃肿：当一个 Service 类变得过于臃肿时，应根据业务流程或业务领域进行合理拆分。例如，将 OrderService 拆分为 OrderCreateService、OrderCancelService 等，使职责更清晰。
- 方法命名：方法名应体现“业务含义”而非“技术动作”。比如createOrder(), calculatePrice()，不要用类似这种handler(), save()命名。
- 业务复用：将复杂流程中的一些步骤抽出来为独立的私有方法，提高代码的可读性和复用性。
- 外部调用：尽量避免在 @Transactional 事务内进行 Redis 写入、MQ 消息发送、HTTP 调用等外部操作，因为这些操作无法随数据库事务回滚，可能导致数据不一致。
Repository/DAO层规范
- 命名规范：接口名通常为 名词 + Repository 或 名词 + Mapper，建议直接用名词 + Mapper看上去简单点。
- 明确查询字段：在编写 SQL 时，避免使用 SELECT *，应明确指定需要查询的字段，以提高查询效率和安全性。（这部分以后会重新开一篇着重讲解查询优化）
- 方法命名：遵循统一的命名前缀，如 get（获取单个）、list（获取多个）、count（统计）、delete（删除）。
疑问：Controller里面接口，某一个接口校验多了，导致代码长了怎么办？
1、使用声明式参数校验，在 DTO 类上使用 @NotNull, @Size, @Pattern 等注解，在 Controller 中使用 @Valid 或 @Validated 注解触发校验。
2、或者直接将校验放到service层，可以参考这样：实现Service 层抛出异常 -> 定义全局异常处理器 -> 返回统一格式给前端
记忆点
代码规范
