[ygra]

This won't work, except for trivial codebases, I guess. Dean Whelton argued a similar thing once [1]. There are always things that resist automated formatting or that are downright destroyed when using it. I use Ctrl+Shift+F or Ctrl+E,D sparingly for that reason. Eclipse has a tendency to mangle Javadoc comments sometimes. Sometimes you're breaking a long method invocation or formula over multiple lines for readability and not exactly at the 80-char boundary, etc.

Of course, trivial things like braces on the same or next line or whitespace around operators are solvable that way, but in general, as long as source code is text (and it will remain that way for quite some time). What perpetuates this state is obviously that we have lots of tools that deal with text and very few that deal with more specialised content. In general I find this sad, though, as text is often neither easiest to work with nor most expressive, despite of what diehard Unix users say.

What would be really lovely in my eyes woul be a source control tool that actually understood its content and could say "order of parameters of that function was changed" or "method added", etc. It's sometimes astonishing how the pursuit of optimal diffs masks the intent of a change where an added method diff starts with the closing brace of the previous method, for example.

[1]: http://welbog.homeip.net/glue/71/Whitespace_is_not_a_problem

[aptwebapps]

"It's sometimes astonishing how the pursuit of optimal diffs masks the intent of a change where an added method diff starts with the closing brace of the previous method, for example."

In Python you can get the whole return statement. Especially when adding a similar type of method, e.g.: Django view functions. Makes

    git add -p

more fun.

[mpyne]

I've found that experimenting with the various git diff algorithms helps out. IIRC there is an "-x patience" flag you can pass to git-diff and tools which use that, which spends more time to get "better" diffs.