Automatic reformatting is evil - sometimes codes is more readable if formatted in a particular way. Readability and maintainability always trumps adhering to rules.
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.
Changing the name of a constant on line three doesn't give you license to autoformat the rest of the file.
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(); } });
filter(myList, new Predicate<Foo>() {
@Override
public boolean apply(Foo foo) {
return foo.isBar();
}
});
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.