[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..