[mseebach]

I know a solution: Agree on the broad points of formatting - ie. tabs/spaces, where the braces generally go. Make engaging in formatting battles a firing offense, but listen to anyone who can make substantial arguments in favour of a practise.

Automatic reformatting is evil - sometimes codes is more readable if formatted in a particular way. Readability and maintainability always trumps adhering to rules.

[lmm]

Automatic reformatting is the only solution, because you want to be able to make unreadable code readable without conscious effort. My preferred policy would be something like:

1. There is an agreed autoformatting template, checked into version control.

2. It is always ok to format the lines you are working on however you like, with the understanding that other people may run the autoformatter on the file.

3. It is always ok to run the autoformatter on a file you are working on (autoformatters only really work at file granularity).

4. It is not ok to format code you are not working on.

[mseebach]

I mostly agree, although I'd like to enhance the bit in point 3 and 4 about only ever reformatting code you're actually working on - meaning, you take responsibility for any code that your autoformatter changes is just as readable as before.

Changing the name of a constant on line three doesn't give you license to autoformat the rest of the file.

[lmm]

I think it does. Carefully maintained manual formatting takes too much programmer effort. If you open a file to actually work on, you should be permitted to hit the autoformat button without thinking, because then formatting becomes something you just don't think about. It's not as good as good manual formatting, but it's good enough, and frees up mental resources for more important things.

[samuellb]

I'd say this depends on the project and the developers. In some projects reading code is done a lot more often (and by more people) than actually writing code, so then you might want to spend more time on e.g. formatting, documenting, etc..

[moocow01]

I guess what Im saying is if you could have a tool that could compare 2 pieces of source code, be able to merge them, and maintain the formatting of each persons local copy it would be great. Its probably a pipe dream because your version control would have to have an intimate knowledge of the specs of any particular language used in the source code (nevermind the version of the language you are using)

[mseebach]

Yes, for merging, that would be incredibly helpful.

But what I'm saying is that the formatting of a file may contain contextual clues that will help someone reading the code to understand what it does. Formatting isn't just chrome around the code.

Example: In Java, when writing a custom predicate to filter by foos that are bars, I prefer

        filter(myList, new Predicate<Foo>() {
            @Override public boolean apply(Foo foo) { return foo.isBar(); } });

to

        filter(myList, new Predicate<Foo>() {
            @Override
            public boolean apply(Foo foo) {
                return foo.isBar();
            }
        });

(filter is statically imported from Collections2 in Guava)

especially when there are multiple of them and they line up neatly underneath each other.

Any meaningful autoformatter would change the latter to the former, and in the process loose readability.

EDIT: Another example would be when using the builder pattern - getting those methods to line up to be neatly readable often takes some none-standard indentation.