Introducing CheckStyle to Improve Java Code Quality
Recently participating in some backend development, I felt the backend code was somewhat messy, with issues like unused imports, unused variables, unreasonable access modifiers, etc. I’ve complained about these issues multiple times before, but always procrastinated on setting standards and promoting standardization. So, taking advantage of the weekend, I made up my mind to tackle this.
Unlike Java, the frontend JS/TS part is effectively controlled at the style level due to Husky+Tslint control. Can’t the backend do the same? It definitely can.
CheckStyle
What to use for control? Regarding technology selection, it seems without question - I previously reviewed ThoughtWorks’ 2019 technology stack statistical report, and for code style control, most chose CheckStyle.
OK, following the crowd.
Usage Methods
Regarding how to use it, there are several ways:
- IDEA plugin
- Maven plugin
- Custom scripts
Choosing Scripts
After consideration, I decided to implement with scripts, for the following reasons:
- The IDEA plugin’s current file scanning scope is all files, and doesn’t support scanning only changed files or files in stage.
The project is open source, so interested parties can submit PRs to support this - Maven plugin can run during the build packaging phase or testing phase, but cannot detect during pre-commit
- Scripts can be written as pre-commit hooks. But a new developer needs to manually execute commands to place the detection hook under .git/hooks.
With the approach determined, let’s get started.
Specific Configuration
Configuration
The required configuration files are as follows:
init.sh is for development initialization deployment, the content is just a copy command.
This doesn't support Windows default shell, but git bash works
#!/bin/bash -e cp pre-commit ../../.git/hooks/ chmod +x ../../.git/hooks/pre-commit
2. pre-commit
The main detection relies on this. For the specific code, [click here](https://gist.github.com/alanhe421/baa359d064b17988bb8cd89a0bbe4c2e). __Note, the file has no extension. The name is a Git hook and cannot be changed.__
3. checkstyle.jar
This is the checkstyle program package
4. google_checks.xml
Custom code style configuration. To modify or add rules, edit this directly.
## Application
### Mac || Linux Users
In IDE, select init.sh, right-click and execute
### Windows
Manually copy `pre-commit` to `../../.git/hooks/`
## Implementation Effect
When committing, if there are errors, the commit fails and will prompt specific error files and line/column numbers.
Just that refreshing.
## Frontend Hook Tool Husky
I've always had a question: how does husky integrate with hooks?
To detect during Git commits, you must deal with hooks. The above operation ultimately puts the checkstyle command we want to execute into the pre-commit hook. So frontend Husky must work the same way, right?
As shown above, when we install the husky package, it actually creates a bunch of Git hooks, and the content is all about executing script commands in husky. You can understand that the script command parameters are the configuration interface husky provides us. Thinking this way, it's actually consistent with our approach above.
Our executing `init.sh` is equivalent to `npm i husky`
## Is Forcibly Controlling Code Style Necessary?
As above, we happily controlled code style. Of course, because it depends on git hooks, if someone just turns off hooks when committing, there's really no way, I've encountered such teammates before.
Admittedly, we can also add detection during build packaging. So after illegal commits that bypass hooks, we can still make these code builds fail and turn red.
But the problem is, these people don't realize the value of unified code style. I think we can only use this image to inspire these people.
## Final Thoughts
After the above configuration, I finally solved a technology stack issue I'd been dragging on, and gained these two insights:
1. Java code style assurance now has an initial solution, and of course can be further optimized, such as whether some errors can be automatically fixed?
2. Gained more understanding of Git's hook mechanism, and also understood how husky is implemented.
## Reference Links
1. [Introduction to CheckStyle](https://www.baeldung.com/checkstyle-java)
2. [Using Checkstyle to Check Code Style](https://juejin.im/post/5bcb56286fb9a05d0e2e9bbc)
3. [Automatic checkstyle check before git commit](https://jimolonely.github.io/2018/09/28/java/007-checkstyle-idea-git-pre-commit/)
4. [Saving Java Code Style OCD](http://insights.thoughtworkers.org/save-java-code-style-obsessive-compulsive-disorder/)
