Philippe>But if possible, I'd prefer that we do not modify too much code only for code style as it might make it difficult to look into particular regressions.
I don't think reformatting would complicate things much. I think it is fine to settle on some rule(s) (e.g. "space after if", or "no wildcard imports" or whatever) and apply the formatting in one go. On the positive side, code style violations could be made to fail the build. That would prevent bad style creeping into the codebase. I have experience with "global reformat" for pgjdbc project (see [1]). That was smooth. Code formatting made the code more consistent (easier to read, easier to update), yet it did not complicate history browsing much. Even thing like "ant -> maven" conversion (with folder reorganization) went fine. Innocent refactoring like "split big class into a couple of more focused ones" brings much more damage in terms of "history traceability". Regular tools like "blame/annotate" give no clue that "this particular method was moved from that particular file". That is why I think it makes sense to just reformat all the files and add relevant checkstyle rules when it comes to simple things like "number of spaces for indentation", "spaces after if", "brace placement". Felix>There would be a lot of warnings. Nobody would look at them after a while I agree here. The rules should result in build failure on violation, and the rules should be easy to configure in IDEs (e.g. autoformat code should produce a compliant code) [1]: https://github.com/pgjdbc/pgjdbc/commit/8f1c9d7bd48de29e3d6dabd0489520ec49d83b25 Vladimir
