Your pipeline now guards main — but think about what it actually checks. Tests prove the code behaves correctly for the cases you thought of. They say nothing about the cases you did not think of, about code nobody can read, or about a password sitting in a string. All of that sails through a green build.
This matters more than ever, because since the core programme you have been writing code with an AI assistant. A 2025 study analysed the Java output of five leading AI models on 4,442 tasks and found that even the code that passed its tests carried on average around two static-analysis findings per task — and when the models introduced a security vulnerability, it was usually of the highest severity, including hardcoded credentials. The models differed; the pattern did not.
<aside> ❗
The lesson is not “do not use AI”. It is: “it compiles and the tests pass” is not a quality standard — whether a human or a model wrote the code. Professionals do not rely on discipline for this; they put another gate in the pipeline.
</aside>
Tests execute your code; static analysis reads it — scanning the source for known problem patterns: suspicious constructs, style violations, unused code, risky calls. Because nothing runs, it is fast, and it inspects all the code, not only the paths your tests visit.
You have already met the idea: the linter from the core programme was static analysis for JavaScript. Today: the same for Java, wired into your pipeline.
Checkstyle checks Java code against a rule set. No account, no service — just a Maven plugin in your pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.6.0</version>
<configuration>
<configLocation>google_checks.xml</configLocation>
<violationSeverity>warning</violationSeverity>
</configuration>
</plugin>
google_checks.xml is a widely used rule set that ships inside the plugin — Google's Java style guide as executable rules. Its findings count as warnings, so violationSeverity: warning tells the plugin that warnings are enough to fail — otherwise the gate would wave everything through. Run it:
mvn checkstyle:check
Expect findings on the first run — indentation, import order, naming. Each one names the file, the line, and the rule. Fix them (your IDE's auto-format handles most) and run again until it passes.
<aside> 💡
The deeper win is not prettiness — it is that style stops being a discussion. In a team, the rule set decides, the gate enforces, and code reviews talk about design instead of spaces. You will be glad for this in every code review of your career.
</aside>
One step in the test job, before the tests — static analysis is fast, so let it fail fast:
- name: Checkstyle
run: mvn --batch-mode checkstyle:check
- name: Run tests
run: mvn --batch-mode verify
From now on, a pull request with style violations goes red before the tests even start — same gate mechanics, new kind of check.
💬 Question: your AI assistant just generated a service class. It compiles, and all tests are green. Which of these can Checkstyle still catch: (a) a calculation that is subtly wrong, (b) an unused import, (c) a hardcoded database password?
Checkstyle is the gentlest member of a family you will meet at work:
They plug into the pipeline in exactly the way you did today — one more step, one more gate. If you can add Checkstyle, you can add any of them.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.