# simple-code-checker

**Repository Path**: jinceon/simple-code-checker

## Basic Information

- **Project Name**: simple-code-checker
- **Description**: 轻松实现代码内置代码规范检查。只读的《代码规范.pdf》压根推行不下去，只有做出《代码规范.exe》才能真正让代码规范落实下来
- **Primary Language**: Java
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-02-24
- **Last Updated**: 2023-04-03

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# simple-code-checker

轻松实现代码内置代码规范检查。只读的《代码规范.pdf》压根推行不下去，只有做出《代码规范.exe》才能真正让代码规范落实下来

## 背景
代码规范一直是个让人头疼的问题。尽管市面上已经存在了一些代码规范检查工具，如pmd和checkstyle，通用的规则已经涵盖了许多常见问题和技术规范。

如for循环的嵌套层数、可能出现的空指针等。但这些规则往往只是纯技术性的规则，无法满足不同团队的个性化业务需求。

因此，团队往往还需要针对自己的开发习惯和项目特点，制定更加具体化和个性化的规则，以便更好地约束和规范代码。


但是现实中，各团队大多依靠wiki等方式来约束和规范代码风格，这种只读的规范往往难以执行落地。

规则的不断增加，团队内人员的流动，需要大量人力和物力进行代码评审，效率极低。

为此，我相信将代码规范内置在代码中，实现自动检查，将是更为有效的解决方案。

这样，开发人员无需再去阅读冗长的规范文字，管理人员也能够更加方便快捷地掌握整个代码的质量情况。

我们可以通过开发一款《代码规范.exe》来实现这一目标。该exe程序可以在项目运行时进行代码规范自检查，若有不符合规范的地方，则及时给出提示，从而实现快速定位和修复问题的目标。

这样，无论是新人还是老手，都可以轻松地遵循代码规范，避免出现不必要的问题和错误。同时，也能够更好地提高代码质量，增强代码的可读性和可维护性。

总之，通过在代码中内置代码规范检查，我们可以更加有效地规范和约束代码风格，从而达到提高代码质量和效率的目的。

## 设计思路及实现
### 自定义规范的定义
本质上是扩展pmd的自定义规则。
1. 编写规则声明。  
   本项目内的规则声明在 `resources/rules`目录下  
   可自行搜索学习pmd的规则声明案例。或在pmd-java.jar包内查看自带的规则`pmd-java-6.54.0-sources.jar!\rulesets\java\`
2. 编写规则实现类。  
   本项目内的规则实现类在 `io.gitee.jinceon.pmd.rules` 包内。
### 代码检查的时机
#### 被否的 git hooks
一开始想过用git hooks 的方式，在提交代码前执行检查，如果有违反规范的代码就不允许提交。像前端的`husky`就是如此。

但 git hooks 是本地钩子（存放在 .git/hooks ），如何实现 .git/hooks 的同步本身就是个问题。

husky的原理是在npm install的时候生成git hook代码，因为每个前端仓库在下载代码后肯定都要执行 npm install 安装依赖。

而 npm 本身提供了 prepare 的 hook，只需要在 package.json 里配置一下接口。

```js
{
  "scripts": {
    "prepare": "husky install"
  }
}
```
#### 依旧被否的 maven 编译时
因为团队内全部成员都是使用intellij idea，开发人员的习惯是在intellij idea直接点`run|debug`来运行项目。

而idea的代码编译是用 `Java Compile API`，根本就没有使用maven，无法实现拦截。

#### 仍然被否的idea 插件 或 CI流水线
提供 idea 插件的话，依赖于开发人员自觉地进行一次主动扫描。

当然这个问题也可以通过 idea 的 File Watcher 插件来实现文件改动的时候自动触发扫描。

但是一来插件本身需要一定的开发成本，二来插件推广本身也有成本。我希望不要每次来新成员的时候都需要重新去教一遍（即使是写好一份新成员指南让人照着做）。

我觉得最好的方式的就是代码内置质量检查。

CI流水线的话就是一个反馈滞后的问题。你得把代码push上去触发构建了，才会知道代码有问题。

同时还会有本地规则和CI上的规则保持同步的问题。

#### 最终采用的程序运行时
项目内 pom.xml 里引入一个依赖。因为项目本身是 SpringBoot，所以利用其 spring.factories 机制实现程序启动时自动加载代码扫描程序。

以编程式的方式启动pmd，检查`src/main/java`目录下的Java源代码（在服务器端直接跳过代码扫描）。

如果存在高级别的代码问题，直接中断 SpringBoot 的运行。

如果你把不符合规范的代码提交了上去，还暴露了你根本就没有进行本地自测。

因为你改了代码，好歹得本地测试一下吧，那你启动项目就必然触发代码检查。
## 使用说明
本项目性质是一个示例项目，向大家展示了如何在项目内实现自定义的代码规范检查。

不建议直接使用本项目，毕竟扩展的代码规范通用性不强，各团队各项目各有自己的需求。  

仅以此项目抛砖引玉，与同行交流。

## 示例规则
1. [不允许在service里获取当前登录用户](./examples/not-allow-get-current-user-in-service-layer.md)
2. [Api返回值必须用R包装](./examples/api-must-wrap-return-value-with-R.md)