On 12 February 2017 at 22:52, Vladimir Sitnikov <[email protected]> wrote: > 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.
My experience is that code reformatting makes history browsing very much harder. > 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
