>I agree with this. Removing formatting from code is really a "lossy
>compression" and it looses lots of valuable information. And it's not just
>that poorly formatted code is often a sign of inexperience or bugs - it's
>also that (at least for me) the style and consistency of a method says a lot
>about who has written it, how many people have been working on it and
>similar things. In short, the way in which a method is formatted reveils a
>lot of subtle information about the writer, its intent and its general
>working style. I am not certain we want to loose that information.

I agree with Andreas about this, but I think it is more a statement about loss in our current formatter than about the impossibility of good automatic formatting.  I think we could get *quite close* to something that made us all happy with just a bit more energy put into the formatter.

For instance...

1.  Include more white space as real information.  I *think* this is what bothers Andreas about lossiness of the current formatter.  For instance, skipping a line between significant sections is one of the most useful gestures in good coding.  Also comments embedded in, or to the right of code are different from line-long comments, and ought to be kept as such.

2.  Make it easy to personalize the formatter with regard to such issues as spaces around binary ops and return arrow, empty line before code, block header spading, etc.  A set of check boxes and a method in view that changes as you check them.

3.  Put some work into the defaults, with input from the community and suggestions like Kent's.

While I know everyone feels differently about various details, I don't think that a wonderful formatter should be considered an impossibility.  I worked pretty hard on the current one years ago, but stopped short of some of the white space subtleties.

It would be nice to have a "benchmark" piece of code that included both challenging structures and tasteful commenting and code.  Then we could all judge whether we basically approved or disapproved of a given formatter (and it's personalizing options).  Each time someone came up with a new challenge, its archetypal example could be added to the benchmark and the formatter tweaked until we were happy with the result.

	- Dan

PS:  On the topic of variable names, I happen to oppose the "aString" style of variable naming except when you really can't think of anything better.  I feel a variable should be typed by its type, and named by its role (ie "boxCount" instead of "anInteger".  Unfortunately we don't have a type inference system and a button to show the types when we want them.  Me, I'm going to keep naming by role, and encouraging work on type inference.