Checkstyle on Changed Files with Gradle
Article Summary
Marc Prengemann from mobile.de faced 30,000+ Checkstyle violations in their Android codebase. Instead of grinding to a halt, his team found a smarter way forward.
The mobile.de Android team integrated Checkstyle into their PR review process but discovered their legacy codebase had tens of thousands of existing violations. Rather than attempting a massive cleanup, they built a custom Gradle task to check only modified files in pull requests, enabling incremental improvement without blocking development.
Key Takeaways
- Custom Gradle task runs Checkstyle only on changed files between branches
- Integrates with GitHub PR builder plugin for automated Jenkins checks
- Uses Git diff commands to identify modified Java files dynamically
- Enables incremental code quality improvement without massive refactoring
A custom Gradle task that runs Checkstyle only on PR changes lets teams enforce coding standards on new code while tackling legacy violations incrementally.
About This Article
Mobile.de's Android team found that Checkstyle flagged over 30,000 code quality issues in their legacy codebase. Fixing all of them in a single development cycle wasn't realistic.
Marc Prengemann's team built a custom Gradle task called checkstyleChanged. It uses Git diff commands and GitHub PR builder environment variables to run Checkstyle only on files that were actually modified between branches.
This incremental approach let the team enforce coding standards on new pull requests while slowly tackling the older violations. Development workflows stayed unblocked and they avoided the need for massive refactoring efforts.