On Sun, Dec 28, 2025 at 11:13 AM Oleg Kalnichevski <[email protected]> wrote:
> Code style is another potentially inflammatory subject. I would be > *strongly* against any post-commit automation that re-formats and > commits formatting changes to the repository. > You're preaching to the choir on this one. I would never, ever stand for something like that. All I'm saying is that an automated Gradle task that finds and fixes Checkstyle violations, according to our existing rules (mandatory `final` for local variables and parameters, no unused imports, etc) would be strictly superior to fixing those things manually. Such a task would of course have to be invoked manually and would not be run as part of the default build tasks. I have my own opinions about the value of code formatting rules generally, and which ones are worth enforcing, but that's not within the scope of the thread. > Event now there is nothing stopping one from > > 1. creating a code style scheme for IntelliJ > 2. extending project's code style to match the IntelliJ scheme [1] > 3. re-formatting the entire code base *once* and committing a single commit > 4. living happily ever after > > Oleg > > [1] https://github.com/apache/httpcomponents-stylecheck I find that code reformatting has significant downsides. It makes `git blame` output meaningless, it creates merge conflicts and makes it difficult or impossible to cherry-pick changes across branches or manage long-lived feature branches, it adds diff noise when comparing releases, it invalidates custom patches maintained by certain companies or linux distros, etc. A recurring annoyance for me when working on Rust codebases is this constant, pointless code churn created by rustfmt, clippy, etc and their ever-changing rules and recommendations. Stability is valuable, even when it comes to the literal text of the source code.
